// application security
Your repositories, measured one by one
L2 counts repositories, not policies. A repository with an open finding is a repository that needs fixing, and the layer says so until it is.
// what it watches
What this layer watches
Application Security reports “Set Up” until the right integration is connected, because until then there is nothing honest to say about it. A platform that showed you green here would be describing an environment it cannot see.
- Source code findings across every connected repository
- Dependency and supply-chain risk inside your own builds, distinct from the third-party risk tracked at L3 Supply Chain
- API surface and how it is authenticated
- Secrets committed where they should not be
// what turns it red
What turns it red
Each row is a live measurement on your own environment, not a checklist item. The third column is the part a compliance-first tool cannot offer.
| What is measured | What it says | Where clicking it takes you |
|---|---|---|
| Source code findings across every repository in a connected organisation | N Repositories Need Fixing | The repository list, filtered to the non-compliant ones |
| Dependency and package risk inside your own builds | N Repositories Need Fixing | The repository record and its finding detail |
| Secrets and credentials committed where they should not be | N Repositories Need Fixing | The repository record, with the finding located |
| Application and API surface, assessed by active scanning against running targets | N Repositories Need Fixing | The application asset and its scan findings |
| Repository configuration: visibility, branch protection and who can merge | N Repositories Need Fixing | The repository record |
| Whether any code host is connected at all | Set Up | The integrations directory, pre-filtered to code hosts |
This table is not the whole check
Repositories, applications, domains, certificates and AI keys are all tracked as first-class assets, each with its own finding types. What one scan looks for depends on what the asset is.
// getting to green
What it takes to go green
- Connect your code hosts. One organisation is enough to start seeing findings.
- Repositories are enumerated and scanned; each finding is attributed to the repository that carries it.
- Findings route to the team that owns the repository rather than to a central compliance inbox.
- The layer clears when no repository carries an open finding.
// the evidence
The evidence this produces
None of this is collected for the auditor's benefit. It is the by-product of work that had to happen anyway, which is why it holds up when someone checks.
- Secure-development evidence for the SOC 2, ISO 27001 and PCI DSS control families — see the SOC 2 guide
- A defensible record of scanning coverage across your estate
- Change and remediation history per repository
// questions this answers
Application security coverage, answered directly
Which code hosts does Konfirmity scan?
GitHub, GitLab, Bitbucket and Azure DevOps. Repositories and projects in any connected organisation are enumerated and scanned, and each finding is attributed to the repository that carries it.
Why does L2 count repositories instead of individual vulnerabilities?
Because remediation is owned per repository. A count of vulnerabilities tells you how noisy your estate is; a count of repositories tells you how many teams need to act, which is the number that predicts how long the work will take.
Do developers have to work inside Konfirmity?
No. Findings route to the team that owns the repository rather than into a central compliance inbox, and the platform tracks the task to closure wherever the fix actually happens.
// keep reading
Where this goes deeper
Want to see this one live?
Book 30 minutes and we will walk through “Your repositories, measured one by one” in the actual platform, using your environment as the example.