diff --git a/src/pages/getting-started/choose-your-path/for-compliance-officers.mdx b/src/pages/getting-started/choose-your-path/for-compliance-officers.mdx
index 2aec369..fc9b3c8 100644
--- a/src/pages/getting-started/choose-your-path/for-compliance-officers.mdx
+++ b/src/pages/getting-started/choose-your-path/for-compliance-officers.mdx
@@ -205,4 +205,4 @@ SBOMs and VEX documents are regenerated on every build, ensuring the data you sh
- [Audit trails](/explanations/compliance/audit-trails) — what gets logged and how to use it for evidence
- [SBOM standards](/explanations/compliance/sbom-standards) — CycloneDX vs SPDX and when to use each
- [Export an SBOM](/how-to-guides/compliance/export-sbom) — generate your first SBOM
-- [Compliance dashboards](/how-to-guides/compliance/attestation-policies#view-compliance-dashboards) — monitoring your compliance posture
+- [Compliance dashboards](/how-to-guides/compliance/track-compliance-postures) — monitoring your compliance posture
diff --git a/src/pages/how-to-guides/compliance/_meta.ts b/src/pages/how-to-guides/compliance/_meta.ts
index 240015b..858a0ab 100644
--- a/src/pages/how-to-guides/compliance/_meta.ts
+++ b/src/pages/how-to-guides/compliance/_meta.ts
@@ -1,9 +1,6 @@
export default {
'audit-logs': { title: 'Audit Logs' },
'export-sbom': { title: 'Export SBOM' },
- 'attestation-policies': {
- title: 'Manage Compliance & Attestation Policies',
- },
'track-compliance-postures': { title: 'Track Compliance Postures' },
'audit-trails': { title: 'DevGuard Audit Trails' },
}
diff --git a/src/pages/how-to-guides/compliance/attestation-policies.mdx b/src/pages/how-to-guides/compliance/attestation-policies.mdx
deleted file mode 100644
index a26252b..0000000
--- a/src/pages/how-to-guides/compliance/attestation-policies.mdx
+++ /dev/null
@@ -1,112 +0,0 @@
----
-title: Manage Compliance & Attestation Policies
-description: "Create compliance-as-code rules and manage DevGuard attestation policies — monitor dashboards, track policy violations, and enforce supply chain security."
-seo:
- robots: index,follow
- og:
- image: /og-image.png
- type: article
- schema:
- type: TechArticle
- keyword_primary: manage compliance & attestation policies
-lang: en-US
-ignoreChecks: null
----
-
-import { Callout } from '@document-writing-tools/kernux-theme'
-import { DocTabs as Tabs } from '@document-writing-tools/kernux-theme'
-import { Badge } from '@/components/ui/badge'
-
-# Manage Compliance & Attestation Policies
-
-Create and manage attestation policies that automatically evaluate compliance requirements across your repositories using compliance-as-code. Monitor compliance status at organization, project, and repository levels.
-
-## Prerequisites
-
-Before you begin, ensure you have:
-
-- Access to a DevGuard organization
-- Admin or owner permissions (for policy creation)
-- Understanding of compliance frameworks (ISO 27001, CRA, etc.)
-- At least one repository with attestations
-
-## What Are Attestation Policies?
-
-Attestation policies are:
-
-- **Compliance-as-code** - Policies written in Rego language
-- **Framework-mapped** - Link to ISO 27001, CRA, SLSA, etc.
-- **Reusable** - Share across organization and projects
-- **Auditable** - Track evaluation results over time
-
-
- Attestation policies use the Rego policy language. They evaluate metadata from attestations (SBOM, VEX, in-toto, etc.) during your CI/CD process to determine compliance.
-
-
-
-## View Compliance Dashboards
-
-### Organization-Level Compliance View
-
-Navigate to **Organization** → **Compliance**
-
-
-
-### Project-Level Compliance View
-
-Navigate to **Organization** → **Project** → **Compliance**
-
-
-
-
- Enabling a policy at the project level tells DevGuard to evaluate that
- policy against this project's repositories. Only organization admins can
- manage project-level policies.
-
-
-### Repository-Level Compliance View
-
-Inspect detailed compliance control evaluations for a specific repository version:
-
-Navigate to **Organization** → **Project** → **Repository** → **Compliance**
-
-
-
-## Navigate to Attestation Policies
-
-Access policy management at organization level:
-
-### Create and Enable Policy
-
-1. Navigate to **Organization** → **Compliance** → **Policies**
-2. Click **Create Policy**
-3. Enter policy details:
- - **Policy name** - Descriptive title
- - **Description** - What it checks
- - **Rego code** - Policy logic
- - **Framework mapping** - Link to ISO 27001, CRA, etc.
- - **Tags** - For organization (security, license, etc.)
-
-[Create Attestation Policy](https://play.openpolicyagent.org/p/DKToCnw0DL)
-
-## Inspect Policy Violations
-
-Understand why a policy failed:
-
-Navigate to **Organization** → **Compliance** → **Policies**
-
-
-
-## Next Steps
-
-- [Export & Publish VEX](/how-to-guides/vex/export-vex) - Document vulnerability assessments
-- [Understand Compliance Frameworks](/explanations/compliance/iso-27001-mapping) - Learn ISO 27001 requirements
-- [CSAF Reports in DevGuard](/how-to-guides/vulnerability-management/csaf-common-security-advisory-framework) - Create compliance-focused security advisories
-- [Export & Publish VEX](/how-to-guides/vex/export-vex) - Document vulnerability assessments
-- [Export SBOMs](/how-to-guides/compliance/export-sbom) - Download component inventories for audit purposes
-
-## Related Documentation
-
-- [Getting Started with DevGuard](/getting-started)
-- [DevGuard How-To Guides](/how-to-guides)
-- [DevGuard Explanations](/explanations)
diff --git a/src/pages/how-to-guides/compliance/audit-logs.mdx b/src/pages/how-to-guides/compliance/audit-logs.mdx
index 15036e4..c5ba601 100644
--- a/src/pages/how-to-guides/compliance/audit-logs.mdx
+++ b/src/pages/how-to-guides/compliance/audit-logs.mdx
@@ -35,7 +35,7 @@ Before you begin, ensure you have:
## View Event Details Across Assets
-For organization-wide compliance tracking, see [Compliance Dashboards](/how-to-guides/compliance/attestation-policies#view-compliance-dashboards) for vulnerability metrics and trends that reflect the cumulative impact of these vulnerability events.
+For organization-wide compliance tracking, see [Compliance Dashboards](/how-to-guides/compliance/track-compliance-postures), where each security control's status is recorded with its own audit trail of who changed it and when.
### Generate PDF Reports for audits
@@ -59,4 +59,4 @@ These reports can be downloaded and provided to auditors as evidence of your vul
- [Compliance Audit Trails](/explanations/compliance/audit-trails) - Understand audit logging concepts
- [CSAF Reports in DevGuard](/how-to-guides/vulnerability-management/csaf-common-security-advisory-framework) - Reports that include event justifications
- [Vulnerability Lifecycle](/explanations/vulnerability-management/vulnerability-lifecycle) - Understand decision workflows
-- [Compliance Dashboards](/how-to-guides/compliance/attestation-policies#view-compliance-dashboards) - View compliance control evaluations and policy violations
+- [Compliance Dashboards](/how-to-guides/compliance/track-compliance-postures) - Track the implementation status of compliance controls
diff --git a/src/pages/how-to-guides/compliance/export-sbom.mdx b/src/pages/how-to-guides/compliance/export-sbom.mdx
index 92fbf94..b8bd3b7 100644
--- a/src/pages/how-to-guides/compliance/export-sbom.mdx
+++ b/src/pages/how-to-guides/compliance/export-sbom.mdx
@@ -54,7 +54,7 @@ for more information on what an SBOM contains, see the [Supplementary SBOMs](/ex
- [Export & Publish VEX](/how-to-guides/vex/export-vex) - Add vulnerability assessments to SBOM
- [CSAF Reports in DevGuard](/how-to-guides/vulnerability-management/csaf-common-security-advisory-framework) - Publish machine-readable advisories
-- [View Compliance Dashboards](/how-to-guides/compliance/attestation-policies#view-compliance-dashboards) - Monitor overall compliance
+- [View Compliance Dashboards](/how-to-guides/compliance/track-compliance-postures) - Monitor overall compliance
## Related Documentation
diff --git a/src/pages/how-to-guides/compliance/track-compliance-postures.mdx b/src/pages/how-to-guides/compliance/track-compliance-postures.mdx
index d7ba614..bca7b78 100644
--- a/src/pages/how-to-guides/compliance/track-compliance-postures.mdx
+++ b/src/pages/how-to-guides/compliance/track-compliance-postures.mdx
@@ -25,13 +25,13 @@ Strip away the audits and paperwork, and compliance reduces to a simple claim: "
So compliance isn't a separate discipline bolted onto secure development - it's the proof layer on top of it. What went wrong in the scenario above wasn't the practices themselves; it's that the proof-gathering happened somewhere organizationally disconnected from where those practices actually live. Compliance Posture closes that gap by putting the tracking directly where the technical decisions are made.
-## What Compliance Posture Is
+### What Compliance Posture Is
**Compliance Posture** is DevGuard's control-tracking dashboard. For every control in a supported catalog, it tracks one thing per organization, project, or repository: is this control **Implemented**, **Not Applicable**, or still **Open**? You back that status up by pointing at things that already exist in your stack - a branch protection rule, a CI job, an SBOM export - instead of writing a paragraph of prose. The result is a living, exportable record instead of a document that's stale the day after you write it.
These decisions also inherit down the hierarchy: mark a control Implemented at the organization level and it applies to every project and repository underneath by default, until one of them decides to record its own, more specific status. That mirrors how these controls actually get satisfied in practice - most are set once centrally (an org-wide branch-protection policy, say) and only a handful of repositories ever need to say something different.
-## How It's Structured
+### How It's Structured
Four terms, introduced in the order you'll actually run into them, using one example throughout: the requirement "restrict who can change source code," satisfied in practice by a GitLab or GitHub branch-protection rule.
@@ -42,13 +42,13 @@ Four terms, introduced in the order you'll actually run into them, using one exa
DevGuard ships with a set of these components already defined and already mapped to controls in the supported catalogs - so for common capabilities like branch protection, the "does this satisfy that control" work is done before you open the dashboard. You can still define your own components for anything specific to your stack.
-## What OSCAL Is, and Why DevGuard Uses It
+### What OSCAL Is, and Why DevGuard Uses It
**OSCAL** (the Open Security Controls Assessment Language) is a specification published by NIST for describing controls, components, and security plans as structured JSON/XML data - think "OpenAPI, but for compliance controls" rather than HTTP APIs.
DevGuard uses it because every framework otherwise defines controls in its own words, at its own level of detail, in its own document format. OSCAL gives DevGuard one shape to import any framework's catalog into and one shape to export evidence back out of, instead of building bespoke support per framework. In practice that means: the BSI catalogs DevGuard ships are imported as OSCAL, components are defined as OSCAL, and **Download OSCAL** on the posture list exports a standard OSCAL System Security Plan - a document any auditor's tooling can parse, not a DevGuard-proprietary report. You never need to read the spec or write OSCAL JSON by hand to use this feature.
-### Why This Matters for Grundschutz++ and the CRA
+#### Why This Matters for Grundschutz++ and the CRA
Picking OSCAL isn't just an internal convenience - it's where the frameworks themselves are heading. The BSI has stopped treating documents as the source of truth for its requirements: its [Stand der Technik Bibliothek](https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek) publishes BSI security requirements as versioned, [machine-readable OSCAL documents](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Grundschutz-in-der-Informationssicherheit/Stand-der-Technik/OSCAL/oscal_node.html) on GitHub, and **Grundschutz++** - the successor to the IT-Grundschutz-Kompendium - is delivered through that library rather than as a compendium you read. That's the explicit goal of the rewrite: state each requirement so a machine can interpret it, so modelling, documentation and eventually the audit itself can be automated. With the public release scheduled for October 2026 and certification starting in January 2027, tooling that can't consume OSCAL will be working from a second-hand copy of a catalog whose authoritative form is data.
@@ -56,20 +56,25 @@ That library is layered much like DevGuard's own model: a **control layer** of c
The **[CRA](/explanations/compliance/cyber-resilience-act)** pushes from the regulatory side toward the same format. No regulation names OSCAL, and the CRA doesn't either - but it already requires one artifact to be machine-readable (the SBOM), and it turns compliance into a continuous, per-product duty instead of a certificate earned once: technical documentation has to stay current across the entire supported lifetime of every product placed on the EU market. That's a volume problem. Evidence for a requirement like "vulnerabilities are handled before release" has to hold per product and per release and be re-provable at any point in the support period - not reconstructed from memory when an auditor asks. And because CRA conformity will in practice be argued through frameworks organizations already run, OSCAL's mapping model is what lets one recorded decision count toward a Grundschutz++ control and a CRA requirement at the same time, rather than being maintained twice in two spreadsheets that drift apart.
-## Compliance Is a Community Effort, Not a Private Chore
+### Compliance Is a Community Effort, Not a Private Chore
The branch-protection component from the example above isn't specific to your organization. Once the mapping from "GitLab branch protection" to a given control exists, it's reusable by every organization running GitLab - nobody else has to rediscover or re-argue it. Connecting a real capability to an abstract control is exactly the kind of work that's tedious to do once and wasteful to redo per company, which is why DevGuard ships common mappings out of the box rather than starting every organization from a blank catalog - and why we're working toward a shared community repository where these component-to-control mappings can be consolidated and improved across organizations, not just shipped once and left to go stale.
This mirrors DevGuard's broader philosophy on [crowdsourced vulnerability assessment](/explanations/vulnerability-management/mitigation-strategies): the same way one team's VEX statement about a vulnerability's exploitability can generalize to every other consumer of that component, one team's work mapping a technical capability to a compliance control generalizes to every other organization with the same setup. The more organizations that attach and refine components, the less redundant interpretation work is left for the next team.
-## Prerequisites
+### Prerequisites
- Access to a DevGuard organization, project or repository (asset).
- Admin or maintain permissions to mark a posture as implemented, not applicable, or to attach a component (read access is enough to view postures).
-## Where to Find Compliance Postures
-The **Compliance Postures** entry sits in the sidebar menu at three levels, and each level shows the same list scoped narrower:
+## Where to find Compliance Postures
+
+To monitor the compliance of your organization, group or repository, DevGuard provides a **Compliance Posture** dashboard at each level. The dashboard shows the status of every control in the supported frameworks, and lets you attach real components as evidence for your decisions.
+
+### Compliance View
+
+The **Compliance Postures** entry sits in the menu at three levels, and each level shows the same list scoped narrower:
- **Organization** → **Compliance Postures** - every control across all supported frameworks, for the whole organization.
- **Project** → **Compliance Postures** - the same controls, scoped to the repositories inside that project.
@@ -79,7 +84,34 @@ A control's status can be decided at any of these levels - see [inheritance](#wh
-## Supported Frameworks
+#### Organization-Level Compliance View
+
+Navigate to **Organization** → **Compliance**
+
+
+
+#### Project-Level Compliance View
+
+Navigate to **Organization** → **Project** → **Compliance**
+
+
+
+
+ Enabling a policy at the project level tells DevGuard to evaluate that
+ policy against this project's repositories. Only organization admins can
+ manage project-level policies.
+
+
+#### Repository-Level Compliance View
+
+Inspect detailed compliance control evaluations for a specific repository version:
+
+Navigate to **Organization** → **Project** → **Repository** → **Compliance**
+
+
+
+
+### Supported Frameworks
Every catalog DevGuard ships out of the box comes from the OSCAL sources the German Federal Office for Information Security (BSI) publishes in its [Stand der Technik Bibliothek](https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek) (see [above](#why-this-matters-for-grundschutz-and-the-cra)):
@@ -94,7 +126,7 @@ Because IT-Grundschutz arrive as mappings onto Grundschutz++ rather than as an u
-## The Compliance Posture List
+### The Compliance Posture List
Open **Compliance Postures** at any level to see a paginated table of controls with their title, framework, control ID, importance, whether a DevGuard component can help satisfy them, and any mapped controls.
@@ -107,7 +139,7 @@ Open **Compliance Postures** at any level to see a paginated table of controls w
-## The Control Detail Page
+### The Control Detail Page
Opening a control shows its full text - description, guidance and assessment objective - with a glossary tooltip on unfamiliar terms, plus a sidebar with its group, class, security level, importance, effort level, tags, source documentation link and mapped controls.
@@ -124,7 +156,7 @@ Every action is recorded in the control's event feed, giving you a full audit tr
-## Attach Components as Evidence
+### Attach Components as Evidence
Attaching a component to a control in your scope is *your* statement that you actually rely on that capability - plus how far along it is:
@@ -151,6 +183,6 @@ To attach one:
## Related Documentation
-- [View Compliance Dashboards](/how-to-guides/compliance/attestation-policies#view-compliance-dashboards) - the older policy/attestation-based compliance view
+- [Audit Logs](/how-to-guides/compliance/audit-logs/) - track decisions via vulnerability event history
- [Cyber Resilience Act](/explanations/compliance/cyber-resilience-act) - what the CRA requires and how DevGuard maps to it
- [Why Compliance Matters](/explanations/compliance/why-compliance-matters) - the business case for compliance
\ No newline at end of file
diff --git a/src/pages/how-to-guides/index.mdx b/src/pages/how-to-guides/index.mdx
index 231d1ab..f506561 100644
--- a/src/pages/how-to-guides/index.mdx
+++ b/src/pages/how-to-guides/index.mdx
@@ -73,7 +73,7 @@ Connect DevGuard with your development platforms:
Ensure your projects meet compliance requirements:
-- [View Compliance Dashboards](/how-to-guides/compliance/attestation-policies#view-compliance-dashboards) — Monitor compliance status across your organization.
+- [View Compliance Dashboards](/how-to-guides/compliance/track-compliance-postures) — Monitor compliance status across your organization.
## API Usage
diff --git a/src/pages/reference/api/compliance.mdx b/src/pages/reference/api/compliance.mdx
index 1cb06a4..10be207 100644
--- a/src/pages/reference/api/compliance.mdx
+++ b/src/pages/reference/api/compliance.mdx
@@ -32,7 +32,7 @@ These endpoints are read-only. Creating and enabling the policies they evaluate
- [Policies API](/reference/api/policies) — defining the policies evaluated here
- [Compliance Postures API](/reference/api/compliance-postures) — mapping results onto a framework control
- [Compliance as Code](/explanations/compliance/compliance-as-code) — the model behind these checks
-- [Attestation Policies](/how-to-guides/compliance/attestation-policies) — writing a policy
+- [Track Compliance Postures](/how-to-guides/compliance/track-compliance-postures) — tracking framework controls in the UI
- [Why Compliance Matters](/explanations/compliance/why-compliance-matters) — background
- [Use the DevGuard API](/getting-started/use-devguard-api) — authentication and conventions
- [DevGuard API Reference](/reference)
diff --git a/src/pages/reference/api/policies.mdx b/src/pages/reference/api/policies.mdx
index 33f36b9..f4a2d75 100644
--- a/src/pages/reference/api/policies.mdx
+++ b/src/pages/reference/api/policies.mdx
@@ -29,7 +29,7 @@ Policy definitions themselves are written in CEL. The [VEX CEL Reference](/refer
## Related Documentation
-- [Attestation Policies](/how-to-guides/compliance/attestation-policies) — writing and applying a policy
+- [Track Compliance Postures](/how-to-guides/compliance/track-compliance-postures) — tracking framework controls in the UI
- [VEX CEL Reference](/reference/vex-cel-reference) — the expression language
- [Compliance API](/reference/api/compliance) — the results of evaluating these policies
- [Compliance as Code](/explanations/compliance/compliance-as-code) — the model behind policies