NIST SSDF evidence on every change
NIST SP 800-218A expects all source code to be evaluated before use. Codacy analyzes every change against your standard, in the IDE and on the pull request.
Trusted by 15,000+ organizations and 200,000+ developers worldwide
How Codacy supports
NIST SSDF compliance evidence
SSDF describes practices, not a certification, so evidence is asked for agency by agency and in vendor questionnaires. These are the practices where Codacy produces records.
Code reviewed or analyzed against your secure coding standards, with issues recorded and triaged
Codacy runs your configured standard on each change, records findings against the pull request that introduced them, and creates Jira Cloud tickets. Triage stays with your team.
Secure coding practices appropriate to the development languages and environment in use
Configure a standard once and Codacy applies it at every commit across every connected repository, running the analyzers built for each of over 40 supported languages.
Well-secured third-party components acquired, and verified against your requirements throughout their life cycle
Known vulnerabilities, malicious packages, licenses and OpenSSF Scorecard data for supported dependencies, reassessed daily, with reachability showing which entrypoints reach the vulnerable code.
Criteria for software security checks defined and tracked through the development life cycle
Quality gates apply configurable issue, security, coverage and duplication thresholds, posting the outcome as a status check.
Vulnerability information on the software and its components gathered from acquirers, users and public sources
Dependencies are reassessed daily against public vulnerability data, including newly disclosed CVEs affecting releases you have already shipped.
Risk responses planned and implemented for each vulnerability found
Configurable remediation deadlines per severity with overdue tracking, and suggested fixes on supported patterns.
“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
NIST SSDF PO,
PW and RV evidence
Connect your Git organization and Codacy analyzes your next pull request. Dated, per-change records from there on.
Gates every change is measured against
Set the thresholds a pull request has to meet and Codacy posts the result as a status check, across every repository in your organization. Whether that holds the merge depends on branch protection, and a repository admin can bypass a check; the result is recorded either way.
Dependencies, rescanned daily
See which components each repository depends on and at which version, with known vulnerabilities, malicious packages, licenses and OpenSSF Scorecard data attached. Reachability shows which entrypoint functions reach the vulnerable code, so life-cycle verification produces a short list instead of a backlog.
Exportable records
PO.3.3 asks that your tools generate artifacts of secure development practice - evidence, in NIST’s own words. Export findings by severity and category as CSV, analysis history as CSV or JSON, and an SBOM from the Dependencies tab.
Re-analysis when rules change
Tighten your standard and Codacy re-analyzes the whole repository, not only the changed lines - which is what RV.1.2 asks for.
Malicious packages at acquisition
PW.4.1 covers what you take on, not only what you write. Malicious packages are flagged in supported manifest files.
Tracked to closure
Set a deadline per severity. Each finding shows whether it is on track, due soon, overdue or closed.
Triaged in your workflow
PW.7.2 asks that findings be triaged in the team’s workflow. Create a Jira Cloud ticket from a finding and triage there.
App and API scanning
PW.8.2 executable-code testing: dynamic scanning of web, OpenAPI and GraphQL targets with OWASP ZAP, triggered from your own workflow.
AI-generated code gets no exemption
NIST SP 800-218A treats AI-generated source code no differently from human-written code. Scan it as it is written with Codacy Guardrails.
Frequently asked questions
How does Codacy support NIST SSDF?
Codacy analyzes every pull request against your secure coding standard, tracks dependency vulnerabilities daily, and records each result against the change. Those records support practices in the Prepare the Organization, Produce Well-Secured Software and Respond to Vulnerabilities groups. Your training, threat modeling and release protections sit outside Codacy.
Can Codacy block a change that fails a check?
Codacy posts a status check and records the result against the pull request. Whether a failing check prevents a merge depends on branch protection in your Git provider, and a repository admin can bypass one on an individual pull request. Codacy’s audit log covers the Codacy app and API rather than your Git provider, and is retained for one year; export for longer.
Does Codacy generate an SBOM?
Yes. Export an SBOM from the Dependencies tab in Security and Risk Management, or generate one in your pipeline with Codacy CLI v2. Codacy also ingests CycloneDX or SPDX SBOMs to scan container images against Trivy’s vulnerability data.
Vendor questionnaire or
agency terms coming up?
Bring the practices you are being asked to evidence, or the questions you are trying to answer. Talk to our team about:
- The repositories and languages in scope for the products you ship.
- The standard you want applied to every change, AI-generated code included.
- The questionnaire, attestation form or contract clause on your desk.