Sectors where this matters
Defense & sovereign
Code classified by national security frameworks cannot be uploaded to commercial SaaS. Most cloud SAST vendors are out of scope.
Relevant: RGS (FR), DoD Instruction 8500.01, NATO STANAG 4774.
Healthcare
HDS (FR), HIPAA (US), GDPR Art. 9 — patient health data flows. The applications that touch them are auditable software, but the source code itself is often classified.
Relevant: HDS, HIPAA, ISO 27799.
Finance
Fraud-detection logic, market-making algorithms, risk models — code that is the IP. Sending it to a SaaS analyzer creates a third-party-risk attack surface most CISOs refuse to accept.
Relevant: DORA, PCI-DSS, ISO 27001 Annex A.
Public sector
RGS (FR), BSI Grundschutz (DE), procurement rules that mandate sovereign hosting and rule out US-based SaaS for sensitive code.
Relevant: RGS, BSI IT-Grundschutz, ENS (ES).
What you get
- ✅ Zero outbound calls during analysis — verifiable with
tcpdump. See the audit log. - ✅ ISO 27001:2022 Annex A compliance matrix (93 controls), pre-filled in the HTML report you hand to your auditor.
- ✅ OWASP ASVS v5.0.0 verifications matrix (348 requirements, 17 chapters).
- ✅ NIST CSF 2.0 mapping (108 subcategories) for US/Canada-aligned compliance.
- ✅ SBOM CycloneDX 1.5 export — required by EU Cyber Resilience Act and US Executive Order 14028.
- ✅ SARIF 2.1.0 export with CWE tags — integrates with GitHub/GitLab Advanced Security dashboards.
- ✅ Sovereign deployment — single binary, runs on Linux/macOS/Windows, no Docker, no JVM, no DB.
- ✅ Pre-written DPO/Legal clause for your supplier risk file. Copy it from here.
Compliance frameworks StaticCodeAudit aligns with
Each finding ships explicit mapping metadata. When you export the SARIF or read the HTML, every issue is traceable to:
ISO/IEC 27001:2022
Annex A controls A.5–A.8. Findings are tagged with the control they evidence (e.g., A.8.4 « Access to source code »).
OWASP Top 10 (2021) + ASVS v5.0.0
Standard reference for application security. ASVS Level 1/2/3 requirements are mapped to specific rules (47 requirements covered).
NIST CSF 2.0
Identify-Protect-Detect-Respond-Recover. Rules tagged with relevant subcategories (PR.DS, DE.CM, etc.) — 108 rules mapped.
CWE / CVE
100% of builtin rules carry at least one CWE identifier. Optional CVE references for rules detecting specific vulnerable library patterns.
WCAG 2.1 (UX/accessibility)
Accessibility findings in HTML / templates map to WCAG 2.1 Level A/AA criteria — useful for public-sector procurement.
Sector-specific frameworks (regulator-recognised)
- Defense / Aerospace — ANSSI guidance (FR), CMMC L2-L3 (US DoD supply chain), MIL-STD-1474.
- Healthcare — HIPAA Security Rule (US), HDS (FR), ISO 27799, FDA 510(k) software validation.
- Finance / Banking — PCI-DSS v4.0 §6.2 secure coding, DORA Art. 8 ICT risk, NIS2 directive, EBA Guidelines on ICT.
- Public Sector — eIDAS, ISO 27001 procurement clauses, ENISA guidelines, NIS2 essential services.
- Energy / Critical Infrastructure — NIS2 Annex I, NERC CIP (US grid), IEC 62443 (industrial), NIST SP 800-82.
Audit evidence that survives a regulator inspection
The HTML report includes every finding's mapping. A regulator's inspector can verify, for any single line of source code:
- Which rule fired (rule ID + version).
- Which standard the rule maps to (CWE, OWASP, ISO, ASVS, NIST CSF).
- What sanitiser or fix is recommended (with code example).
- The severity and the basis for that severity (CWE risk score + organisation context).
- The SHA-256 hash of the binary used (we publish this on our download page).
Because every artefact is plain text or HTML, a regulator can archive the entire evidence package — no proprietary viewer, no SaaS dashboard that might be unavailable in 5 years when an audit is re-opened.
Frequently asked questions (regulated industries)
Does StaticCodeAudit produce a SARIF export compatible with our existing GRC tool?
Yes. SARIF v2.1.0 is the OASIS standard format. Tools like ServiceNow, Jira Security, RSA Archer, MetricStream and Hyperproof ingest SARIF natively. The CLI flag --export sarif produces a single JSON file alongside the HTML report.
Can the binary run in an air-gapped environment (no internet, no DNS)?
Yes. The binary has no network code paths. It reads source files from disk, writes a report to disk, exits. Suitable for SCIF (US), zone restreinte (FR), sicherer Bereich (DE) and equivalent classified-data environments.
What about NIS2 Article 21 — software supply chain attestations?
StaticCodeAudit produces an SBOM in CycloneDX format (--export sbom). Combined with the SARIF findings, this gives the « technical and organisational measures » evidence required under NIS2 Art. 21(2)(d) for affected entities. The CycloneDX SBOM lists dependencies with versions and hashes for procurement chain attestation.
Do you sign your binary so we can verify integrity for HIPAA / SOC 2?
Yes. Each binary release has a SHA-256 hash published on our download page (the same page exposed via /try.php and customer-specific delivery URLs). For Windows, the .exe is signed with an Authenticode certificate. macOS builds are notarised. Linux builds ship with detached signatures.
Is there a self-attestation we can include in our SOC 2 audit?
Yes — our public security page (/security.php) describes the 100% offline architecture and zero-outbound-call posture. We can also provide a signed letter on request for inclusion in a SOC 2 Type II evidence package (contact: contact@codefixture.com).
Talk to a security engineer at CodeFixture
We can sign the data-flow clause for your supplier file, run StaticCodeAudit on a sample of your code via screen-share, and answer compliance questions directly.
Ask the founder directly