Scanning code
Four ways to examine software for weaknesses, and which ones we use.
- Secret scanning
- Searching for passwords, API keys, tokens and private keys in code and in the git history. We do this with gitleaks over the history of your default branch, up to two thousand commits back; we never show the value.
- More about this: Secrets in code
- SAST (static application security testing)
- Reading code without running it, looking for risky patterns such as SQL built from loose text or input that ends up in a shell command. We use semgrep and bandit, at a fixed version.
- More about this: Security scan
- SCA (software composition analysis)
- Checking the third-party components in your software against the public lists of known vulnerabilities. We use osv-scanner on your lockfiles.
- More about this: Dependencies
- DAST (dynamic application security testing)
- Testing a running application from the outside by sending requests at it. We don't do that: we read code and configuration. We look at your public site passively only, and only after you have shown it is yours.
- More about this: GDPR and cookies
- Penetration test
- A person or a tool attacks your running application to see how far they get. We don't do penetration tests: we read code and configuration.
- More about this: Security scan
Components and the chain
Your software is largely made of other people's components. The words that come with that:
- Dependency
- A package from someone else that your application uses, from npm or PyPI. Such a package has packages of its own: the indirect dependencies.
- More about this: Dependencies
- Lockfile
- A file that records exactly which version of every component you use, such as package-lock.json or uv.lock. Without a lockfile nobody knows which version runs live.
- More about this: Dependencies
- SBOM (software bill of materials)
- A list of every component in your software, with its version. The Cyber Resilience Act asks manufacturers to keep track of their components. We don't deliver an SBOM; we show which components have a known problem.
- More about this: Cyber Resilience Act
- Supply chain
- Everything that enters your software from outside: packages, images, pipelines, the tools of your CI. A weak link there is a weak link in your product.
- More about this: NIS2
- End of life
- A runtime or framework that no longer gets security updates. We compare your versions with the support dates.
- More about this: Code quality
- Infrastructure as code
- How your application runs, recorded in files in your repository: a Dockerfile, Kubernetes, Helm, Terraform. We read those files; we don't connect to your cluster.
- More about this: Dockerfile and Kubernetes
Maintenance and knowledge
What keeps an application maintainable in the long run, and how you measure it.
- Technical debt
- Work you put off and pay for later, in slower changes and more bugs. The debt itself can't be measured, but its traces can: complex files that change often and have few tests.
- More about this: Technical debt
- Bus factor
- The number of people who can drop out before nobody can maintain the software any more. At a bus factor of 1 all knowledge sits with one person. We measure it from the git history.
- More about this: Continuity
- Hotspot
- A file that is complex and also changes most often. That is where it hurts first.
- More about this: Code quality
- Test coverage
- How much of the code is exercised by tests. A number doesn't tell the whole story: we also look at whether the report belongs to the commit and whether the pipeline tested anything.
- More about this: Test evidence
- CI (continuous integration)
- The pipeline that builds and tests on every change, such as GitHub Actions or Azure Pipelines. We read its reports with read access; in the pilot we don't run your tests ourselves.
- More about this: Test evidence
Building with AI
The words that come with developing with AI assistants, and what they mean for a check.
- Vibe coding
- Building in conversation with an AI assistant and keeping what works. Development speeds up; whether tests, architecture and documentation keep up is something nobody asks about unprompted.
- More about this: AI-assisted development
- AI code review
- An AI that judges one change in a pull request. We do something else: we check the result, the whole codebase and the evidence in your CI, within a day of every new version.
- More about this: AI-assisted development
- Prompt injection
- Text in a file or on a page that gives an AI assistant instructions that don't come from the user. We search for it in your repository, and our own inspection doesn't follow such text.
- More about this: AI-assisted development
- Instruction file for assistants
- A file such as AGENTS.md that an assistant reads before it works on your code. We count it with the documentation.
- More about this: Documentation
- Verified claim
- What our AI model claims about your code only counts once our code has verified it against the file, the line and the quote. Otherwise it doesn't reach your workspace.
- More about this: How we check