World Backup Day Reminder: Your Code Is Data Too — Are You Protecting It Right?

If the AST platform went down tomorrow with all the scan results, triage decisions, compliance reports, and SBOM snapshots live — what exactly would a team lose? And how long would it take to get it back?

Most teams have never asked this question, because code backups are a solved problem and everything else feels secondary. But the data that surrounds the code is what makes it auditable, insurable, and legally defensible. 

Under the EU Cyber Resilience Act, manufacturers must report actively exploited vulnerabilities within 24 hours starting September 2026, including for products already on the market. 

Under DORA, financial institutions must produce third-party risk documentation on demand. If the data behind those reports doesn’t exist because nobody backed it up, that’s a compliance gap that no amount of re-scanning can cover — because the codebase has changed since the release in question.

 

What Lives Outside Git and Rarely Gets Backed Up

Triage history

Every finding the team marked as false positive, accepted risk, or suppressed — along with the reasoning. Hundreds of previously reviewed vulnerabilities would resurface as “new,” and the team will have to re-litigate every decision from scratch.

SBOM release snapshots

The component inventory tied to a specific shipped version. Lose this, and there’s no answer to “what was in version 2.3.1 that we shipped to that hospital in March” without reconstructing a build environment that may no longer exist.

Compliance reports

The auditor-ready outputs from past scans, mapped to CWE, OWASP, PCI DSS, HIPAA. Lose these, and the last audit’s evidence trail disappears.

Scan configurations and quality gates

Custom rulesets, exclusions, and thresholds that define security policy. Lose these, and it’s a re-tuning of the AST tool from defaults, reintroducing the false positive noise all over again.

Remediation records

Which vulnerabilities were fixed, when, by whom. Without them, there’s no historical narrative of the security posture.

 

The Checklist

Version SBOMs per release

This is the single highest-value practice on this list. Every release ships with a corresponding SBOM snapshot, archived alongside the release artifacts. DerScanner generates SBOMs in CycloneDX format as part of each SCA scan — exporting and tagging them per release is a pipeline step. When a CVE drops in six months and someone asks whether it affects a specific version, the answer easily comes from the archived SBOM.

 

Export compliance reports quarterly

DerScanner’s reporting engine outputs auditor-ready reports mapped to CWE/SANS Top 25, OWASP Top 10, PCI DSS, and HIPAA. Export to PDF, store in the documentation alongside release notes. The worst time to discover compliance reports are gone is during the audit.

 

Preserve triage history

If the AST platform supports exporting triage state, schedule a recurring export. Store it alongside the SBOM. Every suppressed finding represents hours of analyst judgment.

 

Store scan configs in version control

Custom rulesets, quality gate thresholds, exclusion lists — all of it goes into git, alongside the code it governs.

 

Test recovery annually

 

Pick a historical release. Restore the SBOM, the compliance report, the triage state, the scan config. Verify that together they produce a coherent, auditable security posture for that version. A backup that has never been restored is a hypothesis.