How Yknot builds software securely
We build security into a project from the first design discussion through to release. If a feature works but puts data at risk, we treat it as broken and fix it before it ships. Every change reaches production through a pull request that runs a series of automated security checks, and the team reviews each other's work along the way.
We build on recognised industry standards
Good security practice is already well documented, so instead of writing our own rulebook we follow frameworks trusted across the software industry.
The industry's consensus list of the most critical web application security risks. We use it as our baseline checklist: our code must not introduce any of these known classes of weakness.
A structured method, originally developed at Microsoft, for asking “how could this be attacked?” before we build a feature. Any feature that handles sensitive data, money, or user identity goes through this analysis while it is still on the drawing board.
We maintain an internal, control-by-control self-assessment of how our practices map to the ISO 27001 Annex A security controls, and we use it to track and close gaps.
We operate under South Africa's Protection of Personal Information Act. Personal data is never written to logs, never shared with external tools, and is protected by encryption in transit and at rest.
What this looks like in practice
Frameworks are only useful if they change how the work actually gets done. On every project, this is what that looks like.
Your data is protected
- All data is encrypted while travelling over the network, and sensitive data is encrypted where it is stored.
- Personal information never appears in system logs or error reports.
- Access follows the principle of least privilege: every person, service, and system credential gets only the minimum access it needs to do its job.
Access is checked on the server
- Every request is verified on our servers before it is allowed through. We never rely on the user interface alone to hide or restrict anything.
- Access is denied by default, and anything publicly reachable must have a documented reason for being public.
Secrets never leak
- Passwords, API keys, and credentials are stored in a dedicated secrets manager, never in source code.
- Automated scanning runs on every code change and blocks anything that contains a secret before it can be merged.
All input is treated as untrusted
- Every piece of data entering the system is validated against a strict schema on the server.
- Database access goes through vetted, parameterised layers that prevent injection attacks, one of the most common causes of real-world breaches.
The supply chain is watched
- Third-party software libraries are audited automatically on every change. Critical vulnerabilities block the release.
- Dependency versions are pinned, and new libraries are reviewed for maintenance health and provenance before we adopt them.
We watch what runs in production
- Security-relevant events are logged with enough context to investigate any incident.
- When something goes wrong, the system denies access by default instead of letting requests through.
- Users never see raw technical error details, and alerting is in place for authentication failures and access violations.
Nothing ships without passing the gates
Every repository has GitHub branch protection enabled on its production branch. Nobody can push code straight to production, including our own senior engineers. All changes arrive through a pull request, where our pipeline runs:
- 1Automated type checking, linting, and formatting checks
- 2The full automated test suite
- 3A secret scan
- 4A dependency vulnerability audit
- 5Static security analysis of the code itself
- 6Dynamic security testing of the running application, for customer-facing apps
A change that fails these checks does not get merged. Alongside the automated pipeline, the team reviews changes as part of our normal workflow.
AI-assisted development is held to the same standard
AI tools are part of how we build software, and we have clear rules for how they are used:
- AI-generated code goes through the same pipeline and the same review standard as code written by hand.
- Every repository carries explicit security instructions that our AI tooling must follow.
- Client data, credentials, and personal information are never placed into AI prompts or external tools.
Why this matters to you
Because the checks are automated and the standards are written down, security on your project does not depend on any one person remembering to do the right thing. Every release leaves a trail, and if a security question ever comes up we can show you exactly which controls applied and where.
Let's connect
This page is a summary. If your team needs more detail, for example for a vendor security assessment or due diligence process, we are happy to walk through our full internal standards and our ISO 27001 control mapping with you.
