docs(devsecops): add Policy as Code section - #592
Open
s1ns3nz0 wants to merge 2 commits into
Open
Conversation
Sidebar Configuration ReminderThis PR includes added, renamed, or removed documentation files:
Please ensure that:
See Contributing Guide – Sidebar & Navigation for more details. This is an automated reminder. If this PR doesn't need sidebar changes, you can ignore this message. |
Adds docs/pages/devsecops/policy-as-code/ with four pages covering how a policy engine is applied across the CI/CD pipeline, and what NIST SP 800-204D requires of it: - overview: what a policy engine decides, the two evaluation modes (pipeline artifacts versus platform configuration), and the four places the standard names a policy enforcement engine - ci-pipeline: commit, merge, and build gates - release-and-runtime: publishing identity, deployment gates, drift detection - governance: which violations block, who may override, where thresholds come from, and how rules are owned and retired Existing DevSecOps pages document which controls to enable. These cover the decision layer above them, and link out to those pages rather than restating their content. Rego examples are validated against OPA 1.4.2, including the expiring-exception behaviour the governance page relies on. They are fenced as `python` because the site's Shiki bundle has no Rego grammar and an unrecognized language fails the build; the overview page carries a note to that effect. Also: - Registers the section in vocs.config.ts as a nested group with dev: true - Updates the DevSecOps overview contents list - Adds an s1ns3nz0 entry to contributors.json - Adds Rekor to wordlist.txt for the spell check Verified: pnpm run docs:build, cspell, and markdownlint-cli2 all pass. Claude-Session: https://claude.ai/code/session_01CPQ1FcHGiBKWPd8waT7uGx
…standard Applies the standard introduced in security-alliance#561 and the sentence-case heading rule from security-alliance#595: - Renames 'Further Reading & Tools' to 'Further reading' on all four pages - Renames the overview's page map section to 'What this framework covers' - Moves three Rego comments into the surrounding prose The last change is a workaround rather than an improvement. utils/validate-content.cjs extracts headings without stripping fenced code, so a line-start '#' comment inside a Rego block parses as an H1 and any following H3 is reported as heading_level_skip. Noted on the PR. Claude-Session: https://claude.ai/code/session_01CPQ1FcHGiBKWPd8waT7uGx
s1ns3nz0
force-pushed
the
docs/devsecops-policy-as-code
branch
from
July 27, 2026 23:49
213b780 to
89b7610
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR change?
Adds a new
policy-as-codesection under DevSecOps, covering how a policy engine is appliedacross the CI/CD pipeline and what NIST SP 800-204D requires of it.
Four pages under
docs/pages/devsecops/policy-as-code/:platform configuration), and the four places SP 800-204D names a policy enforcement engine
from, and how rules are owned and retired
The existing DevSecOps pages document which controls to enable. These pages cover the decision
layer above them: what the engine evaluates, what evidence each stage produces, and which
decisions a person is allowed to override. Every control referenced here links out to the page
that documents it rather than restating it —
continuous-integration-continuous-deployment,repository-hardening,security-testing,code-signing, and theisolation/pages.Background
This follows a series I recently wrote on NIST SP 800-204D and CI/CD supply chain security:
https://miata.cloud/tags/cicd-security/
The standard's coverage here follows that series. The policy-decision material — rule
classification, threshold derivation, exception handling, and ownership — is new and specific to
this contribution.
On AI assistance
I am not a native English speaker, and I used AI assistance heavily for the English prose. The
structure, scope, and technical decisions are mine, and I verified every claim against its
source:
states that the standard names a policy enforcement engine and names OPA as an example, not
that it mandates either — section 5.1.1 uses "techniques such as," and 5.1.2 uses "(e.g., Open
Policy Agent (OPA))"
the governance page's argument depends on
Flagging this because the contributing guidelines draw a line at content entirely generated by
AI. I do not believe this crosses it, but I would rather say so up front than have it surface in
review.
Notes for reviewers
Rego is fenced as
python. The site's Shiki bundle has no Rego grammar, and an unrecognizedlanguage fails the build. Python is the closest available approximation and highlights Rego
reasonably. There is a note to that effect at the bottom of the overview page. Happy to switch to
an unhighlighted fence if you would prefer accuracy over readability here.
Folder rather than a single page. The material ran past 1,500 lines. Following the structure
of
devsecops/isolation/, it is split into four pages of 257–526 lines each, which is within therange of existing DevSecOps pages.
Normalization standard. Rebased onto
developand applied the standard from #561 and thesentence-case rule from #595:
Further readinginstead ofFurther Reading & Tools, andWhat this framework coversfor the overview's page map.pnpm run validate:content --path docs/pages/devsecops/policy-as-codereports 4 passed, 0 failed.One validator issue worth flagging.
utils/validate-content.cjsextracts headings withoutstripping fenced code blocks, so a line-start
#comment inside a code block parses as an H1.Any
###that follows is then reported asheading_level_skip. This fired on two of thesepages because Rego uses
#for comments. I worked around it by moving the comments into thesurrounding prose, but the same thing will hit any page with Python, Ruby, shell, or YAML
comments at line start. The fix is a one-line change: run
stripCode(body)beforeheadings().Happy to open a separate PR for that if useful.
Verification
pnpm run docs:buildpassespnpm run validate:content --path docs/pages/devsecops/policy-as-code: 4 passed, 0 failedcspellclean (addedRekortowordlist.txt)markdownlint-cli2reports 0 issues across all four pagesType of change
If applicable
vocs.config.tswith thedev: trueparameter