What an auditor, or Sekit's evidence engine, asks for.
Secure development policy
The rules the development team follows to build software securely: security requirements, code review and threat modeling.
Application security testing evidence
The proof that code and applications are automatically scanned for flaws (SAST/DAST), including dependencies and APIs.
From the Sekit evidence catalog
In practice
Secure coding in practice means an automated scanner wired into the development workflow, catching common flaws like injection or broken access control before a human reviewer sees the change. Auditors want to see the scanner running on every pull request, not configured once and then ignored as findings pile up unreviewed. The failure mode that keeps recurring is a scanner that flags real issues, but the findings sit in a backlog nobody triages, so the control exists on paper while the same vulnerability class keeps shipping to production release after release.
Common gaps
The code security scanner is configured but its findings are not triaged, so several known vulnerability classes have shipped to production repeatedly.
Secure coding standards exist for the main application but are not enforced on scripts and internal tools built by the same team.
The scanner runs on pull requests to the main branch but is not wired into feature branches, so issues surface late in the review cycle.
Questions your auditor will ask
How do you catch common coding flaws like injection before release?
An automated code security scanner is wired into the development workflow so every change is checked without relying on manual effort.
What happens when the scanner finds a vulnerability?
The finding is triaged as part of the workflow, and the application security testing evidence shows scan results tracked to resolution rather than left open.
Does secure coding cover internal tools, or only the main application?
The same scanner and coding standard apply wherever the development team writes code, so internal tools go through the same check as customer-facing software.
Where regulation demands it
NIS2 art. 6.5 requires security testing to catch coding flaws, and ENS mp.sw.1 requires secure application development practices, both of which automated scanning directly supports.
Related controls
Via the shared Sekit CSF topic, not the framework's own index.