Secure coding evidence for ISO 27001, on every pull request
Codacy analyses every change against your configured security rules and records the result against the merge.
Trusted by 15,000+ organizations and 200,000+ developers worldwide
How Codacy supports
ISO 27001 compliance evidence
Codacy produces evidence for the technological controls that govern how code is written, tested and merged, where they’re in scope in your Statement of Applicability. Here is where it applies.
Security integrated across the SDLC, inception to deployment
The controls above are the code-stage part of that lifecycle, applied consistently across every connected repository.
Security requirements defined and specified before development begins
The requirements you define that are automatically testable become rules and thresholds Codacy enforces. Codacy evidences that they’re applied, not that they were defined.
Secure coding principles applied throughout development, with evidence that security issues cause code to be rejected
Shared security rule sets applied to every repository. Findings are surfaced on the pull request that introduced them, and a failing gate blocks the merge.
Code tested for functional and security requirements before release; includes both vulnerability scanning and penetration testing
Static analysis of source code, plus dynamic scanning of running applications and APIs, triggered from your pipeline. Penetration testing is a separate requirement, available through our partner.
Changes tested and formally approved before deployment
Gates block the merge until checks pass and a reviewer approves. The check result and the approval are recorded against the pull request. Configuration changes to Codacy itself are recorded in the audit log.
Vulnerabilities identified in a timely way, risk-evaluated, and remediated to a deadline
Daily rescans of open-source dependencies, severity-ranked findings, configurable remediation deadlines with overdue status, and CSV export for review.
“Codacy has improved communication between security and development teams, and it’s continuing to raise the bar for compliance.”
David Morton Manager of Security Operations at Genesys
ISO 27001 A.8 evidence
for engineering leaders
Connect your Git organisation in two clicks. First evidence report the same day.
Merge gates with a recorded result
Set the checks a pull request has to pass before it can merge. Each gate produces a timestamped record of what was tested, what the outcome was, and who approved the change. When an auditor samples changes, you export those records.
One rule set, applied everywhere
Configure your secure coding standard once, from OWASP and CWE-aligned rules, and Codacy applies it at every commit across every connected repository. Auditors sampling A.8.28 want to see that the standard exists, that it’s applied consistently, and that it has consequences. A blocked merge is that consequence.
Static and dynamic analysis
SAST reads your source code for supported vulnerability classes. DAST tests your running applications and APIs, on demand from your pipeline. A.8.29 asks for both, plus penetration testing, which we cover through our partner, WorkNest Secure.
SAST on every commit
Injection patterns, insecure cryptography, and authentication and authorization weaknesses, identified before merge.
Daily dependency rescans
Dependencies are reassessed between commits, so a vulnerability disclosed today surfaces today, not at the next code change.
Deadlines and overdue status
Set a remediation deadline per severity. Each finding shows its age, its status, and whether it has gone overdue.
Enforced coding standards
Configure a rule set once. It is applied at every commit across every repository.
Audit log of configuration changes
Changes to your Codacy analysis settings are recorded, so you can show the standard wasn’t quietly loosened.
CSV findings export
Export severity-ranked findings for your security review, risk register or auditor sample.
Frequently asked questions
How does Codacy support ISO 27001 certification?
Codacy analyses code changes against your configured security rules and records the results. Those records support the technological controls covering secure coding, change checks and vulnerability management, alongside evidence from your policies, risk assessment and other systems.
Do we need this before our certification audit?
Auditors assessing A.8.28 look for evidence that secure coding rules are applied and that security issues have caused code to be rejected. That evidence accumulates as your team merges code, so a tool switched on the week before the audit has little to show. Teams typically want it running for at least a full development cycle beforehand.
Can Codacy block a change that fails a check?
Yes, when Codacy status checks are configured as required checks in your Git provider. Your branch protection settings determine whether a failing check prevents a merge.
ISO 27001 Certification
audit coming up?
See your first evidence report today. Bring your Statement of Applicability or the questions you’re trying to answer. Talk to our team about:
- The repositories and languages in your ISMS scope.
- The secure coding rules you want applied to every change.
- The records your auditor will sample.