Skip to content

Commit 34b8d74

Browse files
l3monKenjil3monKenji
committed
adds compliance-officers-path documentation
Signed-off-by: Frédéric Noppe <frederic.noppe@l3montree.com>
1 parent 01f14c0 commit 34b8d74

1 file changed

Lines changed: 204 additions & 4 deletions

File tree

‎src/pages/getting-started/choose-your-path/for-compliance-officers.mdx‎

Lines changed: 204 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,9 +1,209 @@
11
---
2+
title: DevGuard for Compliance Officers - Software Compliance Management
3+
description: How DevGuard helps compliance officers prove and maintain software compliance across every project — covering CRA, NIS2, PCI DSS, and ISO 27001 with automated evidence, audit trails, and shift-left compliance as code in CI/CD pipelines.
24
seo:
3-
robots: "noindex, nofollow"
5+
keyword_primary: "software compliance"
6+
keywords_secondary:
7+
- "software compliance automation"
8+
- "CRA compliance software"
9+
- "NIS2 compliance DevSecOps"
10+
- "ISO 27001 software development"
11+
- "PCI DSS vulnerability management"
12+
- "compliance as code CI/CD"
13+
og:
14+
type: "article"
415
---
5-
import PageContentComingSoon from '@/components/PageContentComingSoon'
616

7-
# DevGuard for Compliance Officers
17+
# DevGuard for Compliance Officers - Software Compliance Management
818

9-
<PageContentComingSoon />
19+
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.
20+
21+
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.
22+
23+
---
24+
25+
## What DevGuard gives you
26+
27+
### A continuous compliance evidence base
28+
29+
Every time a developer pushes code or builds a container image, DevGuard automatically generates and stores compliance evidence:
30+
31+
- **Software Bill of Materials (SBOM)** — a machine-readable inventory of every component, version, and dependency, in CycloneDX or SPDX format
32+
- **Vulnerability scan results** — from SCA, SAST, container scanning, secret scanning, IaC scanning, and DAST
33+
- **VEX documents** — structured assessments of which vulnerabilities actually affect your product, reducing noise for auditors and customers
34+
- **CSAF advisories** — machine-readable security advisories aligned to industry standards
35+
- **Signed attestations** — cryptographically signed records proving which checks ran and what they found, stored alongside your container images
36+
37+
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.
38+
39+
### Immutable audit trails
40+
41+
Compliance frameworks require more than running a scan—they require demonstrating how vulnerabilities were handled. DevGuard logs every event in the vulnerability lifecycle:
42+
43+
- When a vulnerability was first detected
44+
- Risk score evolution over time (with reasoning: new exploit data, EPSS changes, patch availability)
45+
- Every state transition: under investigation → not affected → fixed → accepted risk
46+
- Who made each decision, when, and with what justification
47+
- When components were removed (automatic remediation evidence)
48+
49+
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.
50+
51+
### Risk-based prioritization, not CVE counts
52+
53+
Compliance doesn't mean fixing every CVE—it means demonstrating a risk management process. DevGuard calculates a composite risk score per vulnerability that combines:
54+
55+
- **CVSS Base Score** (v2, v3, v4)
56+
- **EPSS** — the statistical probability of exploitation in the wild
57+
- **Threat intelligence** — known active exploits, CISA KEV entries, verified public exploits
58+
- **Environmental context** — confidentiality, integrity, and availability requirements you configure per asset
59+
- **Transitive depth** — how deep in the dependency tree the vulnerable component sits
60+
61+
This lets you show auditors a prioritized, risk-justified remediation backlog rather than an unmanageable list of raw CVE counts.
62+
63+
---
64+
65+
## Software Compliance Framework Coverage
66+
67+
### EU Cyber Resilience Act (CRA)
68+
69+
The CRA mandates cybersecurity requirements for products with digital elements sold in the EU. Key obligations DevGuard addresses:
70+
71+
| CRA Requirement | DevGuard Capability |
72+
|-----------------|---------------------|
73+
| SBOM per product | Automatic CycloneDX/SPDX generation on every build |
74+
| Vulnerability identification and documentation | Continuous SCA, container scanning, SAST, DAST |
75+
| Handling vulnerabilities without undue delay | Audit-trailed remediation workflow with SLA tracking |
76+
| Reporting of actively exploited vulnerabilities | EPSS + CISA KEV integration surfaces exploited CVEs immediately |
77+
| Providing security updates | SBOM and VEX docs updated with every build |
78+
| Disclosure of fixed vulnerabilities | CSAF advisory generation |
79+
80+
### NIS2 Directive
81+
82+
NIS2 requires organizations in critical sectors to implement risk management measures for their software and supply chains:
83+
84+
| NIS2 Obligation | DevGuard Capability |
85+
|-----------------|---------------------|
86+
| Risk management policies | Policy-as-Code with OPA/Rego, enforced in CI/CD |
87+
| Supply chain security | SBOM generation, dependency vulnerability scanning, SLSA attestations |
88+
| Vulnerability disclosure and handling | Automated lifecycle tracking with audit trails |
89+
| Incident response evidence | Timestamped event logs, state-change history |
90+
| Security testing | SAST, DAST, container scanning integrated into every pipeline |
91+
92+
### PCI DSS
93+
94+
PCI DSS requires organizations handling card data to maintain vulnerability management programs and security testing practices:
95+
96+
| PCI DSS Requirement | DevGuard Capability |
97+
|--------------------|---------------------|
98+
| 6.3.3 — Security patches applied in a timely manner | SCA identifies outdated, vulnerable dependencies with patch guidance |
99+
| 6.4.1 — Web-facing apps protected against known attacks | DAST testing of running applications |
100+
| 6.4.2 — Automated technical solution for detecting and preventing attacks | Continuous scanning in CI/CD pipelines |
101+
| 6.3.2 — Inventory of bespoke and custom software | SBOM per build, tracked per asset |
102+
| 11.3 — Vulnerability scanning | SCA, SAST, container scanning with documented results |
103+
| 12.3.2 — Targeted risk analysis | Risk scoring with environmental context per asset |
104+
105+
### ISO 27001
106+
107+
DevGuard maps directly to the Annex A.8 technological controls that affect software development:
108+
109+
| ISO 27001 Control | DevGuard Capability |
110+
|-------------------|---------------------|
111+
| A.8.8 — Technical vulnerability management | Full lifecycle: discovery, risk scoring, remediation tracking, audit trail |
112+
| A.8.25 — Secure development lifecycle | OWASP DevSecOps pipeline integration, SLSA threat model coverage |
113+
| A.8.28 — Secure coding | SAST, secret scanning, SCA, license compliance |
114+
| A.8.29 — Security testing | SAST, DAST, container scanning, IaC scanning as CI/CD gates |
115+
| A.8.4 — Access to source code | in-toto integrity attestations on build artifacts |
116+
| A.8.7 — Protection against malware | Dependency and container vulnerability scanning |
117+
| A.8.19 — Software installation | SBOM tracks all installed components and versions |
118+
119+
See the full [ISO 27001 controls mapping](/explanations/compliance/iso-27001-mapping) for detailed coverage.
120+
121+
---
122+
123+
## Compliance as Code: Shifting Left on Software Compliance
124+
125+
Traditional software compliance is a post-development activity—security reviews happen before releases, audits after incidents. This creates pressure spikes, delays, and expensive rework.
126+
127+
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.
128+
129+
### How it works
130+
131+
DevGuard's policy engine is built on [Open Policy Agent (OPA)](https://www.openpolicyagent.org/) 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.
132+
133+
**What you can enforce as a policy gate:**
134+
135+
- Block container images with critical vulnerabilities from being deployed
136+
- Require SBOM generation before any release
137+
- Require signed images and verified build provenance (SLSA)
138+
- Enforce that SAST scans ran and found no high-severity issues
139+
- Validate that infrastructure-as-code was scanned for misconfigurations
140+
- Require secret scanning to pass before merging
141+
- Check license compliance for all dependencies
142+
143+
**Community policies vs. custom policies:**
144+
145+
DevGuard ships with community-managed policies pre-aligned to ISO 27001, CRA, and SLSA. You can:
146+
147+
- Enable or disable community policies per project
148+
- Write custom Rego policies for your specific regulatory requirements
149+
- Map policies to compliance controls for audit evidence
150+
151+
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.
152+
153+
### The shift-left benefit for compliance officers
154+
155+
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:
156+
157+
- **Before:** "We found 47 unresolved CVEs during the pre-release audit. Release is blocked."
158+
- **After:** "Our pipelines have been enforcing the policy continuously. Here is the evidence."
159+
160+
Audit preparation becomes a report export rather than a fire drill.
161+
162+
---
163+
164+
## License compliance
165+
166+
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.
167+
168+
For each license finding, you can:
169+
170+
- Record a decision with business justification
171+
- Override the detected license for a specific component
172+
- Make a final binding decision that becomes part of the audit trail
173+
174+
---
175+
176+
## Reporting and exports
177+
178+
| Report | Format | Use case |
179+
|--------|--------|----------|
180+
| **SBOM** | CycloneDX JSON / XML, SPDX | CRA compliance, customer requests, supply chain transparency |
181+
| **VEX** | CycloneDX JSON / XML | Share exploitability context with customers or regulators |
182+
| **CSAF advisory** | JSON | Machine-readable vulnerability advisories |
183+
| **Vulnerability report** | PDF | Audits, executive briefings |
184+
185+
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.
186+
187+
---
188+
189+
## Recommended first steps
190+
191+
1. **Identify your applicable frameworks** — CRA, NIS2, ISO 27001, PCI DSS, or a combination
192+
2. **Enable relevant community policies** for your compliance framework under Organization settings
193+
3. **Integrate scanning into your CI/CD pipelines** — the [GitHub integration](/how-to-guides/integrations/github/setup-github-integration) or [GitLab integration](/how-to-guides/integrations/gitlab/setup-gitlab-integration) gets scanning running across all repositories
194+
4. **Configure asset risk requirements** — set confidentiality, integrity, and availability levels per asset to calibrate risk scoring to your business context
195+
5. **Run your first compliance dashboard review** — review open vulnerabilities, their risk scores, and current remediation status
196+
6. **Export an SBOM** for a representative product — verify it meets the format requirements your auditors or customers expect
197+
7. **Write VEX rules** for confirmed false positives — reduce noise so auditors see only what matters
198+
199+
---
200+
201+
## What's next
202+
203+
- [Compliance as Code](/explanations/compliance/compliance-as-code) — how policies are enforced in CI/CD pipelines
204+
- [ISO 27001 mapping](/explanations/compliance/iso-27001-mapping) — detailed Annex A control coverage
205+
- [Why compliance matters](/explanations/compliance/why-compliance-matters) — business case and regulatory context
206+
- [Audit trails](/explanations/compliance/audit-trails) — what gets logged and how to use it for evidence
207+
- [SBOM standards](/explanations/compliance/sbom-standards) — CycloneDX vs SPDX and when to use each
208+
- [Export an SBOM](/how-to-guides/compliance/export-sbom) — generate your first SBOM
209+
- [Compliance dashboards](/how-to-guides/compliance/compliance-dashboards) — monitoring your compliance posture

0 commit comments

Comments
 (0)