DevGuard for Compliance Officers - Software Compliance Management#

As a compliance officer, your job is to prove software compliance: that software is developed and operated securely, to auditors, regulators, customers, and management. The challenge is that modern software is complex, changes continuously, and spans dozens of teams and hundreds of dependencies.

DevGuard embeds software compliance into the development lifecycle itself. Rather than collecting evidence after the fact, it generates verifiable proof of every security check, vulnerability decision, and policy evaluation automatically—as part of every build.

What DevGuard gives you#

A continuous compliance evidence base#

Every time a developer pushes code or builds a container image, DevGuard automatically generates and stores compliance evidence:

• Software Bill of Materials (SBOM) — a machine-readable inventory of every component, version, and dependency, in CycloneDX or SPDX format
• Vulnerability scan results — from SCA, SAST, container scanning, secret scanning, IaC scanning, and DAST
• VEX documents — structured assessments of which vulnerabilities actually affect your product, reducing noise for auditors and customers
• CSAF advisories — machine-readable security advisories aligned to industry standards
• Signed attestations — cryptographically signed records proving which checks ran and what they found, stored alongside your container images

This evidence is version-tracked and immutable. For any release, you can look back and show exactly what was known, what was scanned, and what decisions were made.

Immutable audit trails#

Compliance frameworks require more than running a scan—they require demonstrating how vulnerabilities were handled. DevGuard logs every event in the vulnerability lifecycle:

• When a vulnerability was first detected
• Risk score evolution over time (with reasoning: new exploit data, EPSS changes, patch availability)
• Every state transition: under investigation → not affected → fixed → accepted risk
• Who made each decision, when, and with what justification
• When components were removed (automatic remediation evidence)

This directly answers the questions auditors ask: "How did you find out about this CVE? Who decided to accept the risk? When was it fixed?" No manual reconstruction needed.

Risk-based prioritization, not CVE counts#

Compliance doesn't mean fixing every CVE—it means demonstrating a risk management process. DevGuard calculates a composite risk score per vulnerability that combines:

• CVSS Base Score (v2, v3, v4)
• EPSS — the statistical probability of exploitation in the wild
• Threat intelligence — known active exploits, CISA KEV entries, verified public exploits
• Environmental context — confidentiality, integrity, and availability requirements you configure per asset
• Transitive depth — how deep in the dependency tree the vulnerable component sits

This lets you show auditors a prioritized, risk-justified remediation backlog rather than an unmanageable list of raw CVE counts.

Software Compliance Framework Coverage#

EU Cyber Resilience Act (CRA)#

The CRA mandates cybersecurity requirements for products with digital elements sold in the EU. Key obligations DevGuard addresses:

NIS2 Directive#

NIS2 requires organizations in critical sectors to implement risk management measures for their software and supply chains:

PCI DSS#

PCI DSS requires organizations handling card data to maintain vulnerability management programs and security testing practices:

ISO 27001#

DevGuard maps directly to the Annex A.8 technological controls that affect software development:

See the full ISO 27001 controls mapping for detailed coverage.

Compliance as Code: Shifting Left on Software Compliance#

Traditional software compliance is a post-development activity—security reviews happen before releases, audits after incidents. This creates pressure spikes, delays, and expensive rework.

DevGuard flips this model. Software compliance checks run automatically inside every CI/CD pipeline, so developers discover and fix violations while they still have context—not weeks later during a review cycle.

How it works#

DevGuard's policy engine is built on Open Policy Agent (OPA) and evaluates policies written in Rego against the attestations generated by each pipeline run. Every scan result, SBOM, and build artifact becomes a piece of compliance evidence that policies can reason about.

What you can enforce as a policy gate:

• Block container images with critical vulnerabilities from being deployed
• Require SBOM generation before any release
• Require signed images and verified build provenance (SLSA)
• Enforce that SAST scans ran and found no high-severity issues
• Validate that infrastructure-as-code was scanned for misconfigurations
• Require secret scanning to pass before merging
• Check license compliance for all dependencies

Community policies vs. custom policies:

DevGuard ships with community-managed policies pre-aligned to ISO 27001, CRA, and SLSA. You can:

• Enable or disable community policies per project
• Write custom Rego policies for your specific regulatory requirements
• Map policies to compliance controls for audit evidence

When a policy fails, the pipeline stops and the developer sees exactly which software compliance requirement was not met—with a link to the relevant documentation. Feedback happens at the point where it costs the least to fix.

The shift-left benefit for compliance officers#

When developers get software compliance feedback in their normal workflow, you stop being the department that blocks releases and start being the team that enabled a compliant delivery process from the beginning. This changes the conversation:

• Before: "We found 47 unresolved CVEs during the pre-release audit. Release is blocked."
• After: "Our pipelines have been enforcing the policy continuously. Here is the evidence."

Audit preparation becomes a report export rather than a fire drill.

License compliance#

Open-source licenses can create legal exposure if not managed proactively. DevGuard scans all dependencies for license information and flags components whose licenses conflict with your project's model or internal policy.

For each license finding, you can:

• Record a decision with business justification
• Override the detected license for a specific component
• Make a final binding decision that becomes part of the audit trail

Reporting and exports#

SBOMs and VEX documents are regenerated on every build, ensuring the data you share reflects the current state of each release—not a snapshot from last quarter.

Recommended first steps#

1. Identify your applicable frameworks — CRA, NIS2, ISO 27001, PCI DSS, or a combination
2. Enable relevant community policies for your compliance framework under Organization settings
3. Integrate scanning into your CI/CD pipelines — the GitHub integration or GitLab integration gets scanning running across all repositories
4. Configure asset risk requirements — set confidentiality, integrity, and availability levels per asset to calibrate risk scoring to your business context
5. Run your first compliance dashboard review — review open vulnerabilities, their risk scores, and current remediation status
6. Export an SBOM for a representative product — verify it meets the format requirements your auditors or customers expect
7. Write VEX rules for confirmed false positives — reduce noise so auditors see only what matters

What's next#

• Compliance as Code — how policies are enforced in CI/CD pipelines
• ISO 27001 mapping — detailed Annex A control coverage
• Why compliance matters — business case and regulatory context
• Audit trails — what gets logged and how to use it for evidence
• SBOM standards — CycloneDX vs SPDX and when to use each
• Export an SBOM — generate your first SBOM
• Compliance dashboards — monitoring your compliance posture