◐partialWhich policy decisions were actually enforced against the infrastructure definitions the boundary deploys from: that a policy scan ran, on which branch, how many rules it applied and when it last ran, together with the failures still open and the record of which were dismissed and with what justification. The load-bearing half is the scan record rather than the findings. SA-08 asks whether security engineering principles were applied, and a clean findings list is the same output whether every principle held or the scan applied no rules, ran last quarter, or parsed nothing — so the count of rules run and the date it ran are the part of this evidence that makes the rest of it mean anything.continuouscli
infrastructure-policy-scan-coverage-and-deviationsCheckov · GitHub code scanning
WHY PARTIAL, STATED AGAINST THE CONTROL'S OWN LIMBS. SA-08 requires the principles to be applied in specification, design, development, implementation and modification. Implementation is the limb a pipeline can see — a rule that fails a world-readable bucket or an over-broad role is telemetry about layered protection or least privilege actually holding in the artifact being deployed — and it is one limb of five. Which principles were selected, and how they were applied in specification and design, is an SDLC document; a passing rule evidences A principle without naming the one that was chosen. The dataset in this repo carries no FedRAMP-specific parameter or guidance for SA-08 at all, so there is no organization-defined value here to read a selection out of, which is the same absence SA-22 has and it lands in the same place: the selection is the provider's to write down.
THE INLINE SUPPRESSION BLIND SPOT, AND IT IS THE LARGEST ONE HERE. Checkov's documented suppression syntax is a comment of the form `checkov:skip=<check_id>:<suppression_comment>`, and the documentation is explicit that the comment is OPTIONAL. A check suppressed that way is not a finding: it produces no SARIF result, so it never becomes an alert, so no clause in this recipe can see it, and the suppression can carry no stated reason at all. The dismissal clause below reads dismissals made in the PLATFORM, which is a different act by a different person leaving a different record. A boundary can therefore hold a green alert list and a repository full of skips, and the two facts are collected by different commands here on purpose.
WHY `scan-json` AND `version` ARE COLLECTED AND NOT ASSERTED. The third command is how a reader enumerates the skipped checks the paragraph above describes, along with parse errors and the resource count — the scan that parsed nothing is the vacuity case that reaches the alert list looking identical to the clean one. No clause reads it, because Checkov's JSON schema is not documented on any page cited here, and this repo does not assert over field names it has not verified. That is a limit of the citation and it is written down rather than papered over with a plausible path; a batch that fetches a schema for it can add the clauses and should.
`--soft-fail` IS THE OTHER WAY THIS GOES GREEN. Checkov documents `--soft-fail` as "Runs checks but always returns a 0 exit code". A workflow can run the scan, upload the SARIF, populate every report this recipe reads, and never block a merge. Nothing in the analyses or alerts output says whether the scan gates anything — that question is a ruleset question and it belongs to the sibling recipes on CM-04 (02) and SA-10, which read required status checks and rule suites directly. Read this recipe as evidence that the policy scan RUNS and what it FINDS, never as evidence that a failing policy stops a deployment.
WHAT THE DISMISSAL CLAUSE ESTABLISHES. `dismissed_reason` is documented required, string or null, with five values: `false positive`, `won't fix`, `used in tests`, `mitigated` and null. An earlier reading of that page recorded three of them and built this paragraph on `won't fix` alone, which was the wrong shape twice over — the enum was short, and `mitigated` is a direct competitor for the role the paragraph was giving `won't fix`. Both are records that a policy failure was closed by a decision rather than by a fix, and they say different things: `won't fix` is a principle deliberately not satisfied in a named place, `mitigated` is a claim that something else covers it, and THAT claim is a compensating-control argument no field here carries the text of. Between them they are the closest thing this plane holds to a recorded deviation, and the clause below asserts of both only that a justification was typed. The clause asserts that a justification was TYPED, not that it was a good one, and a dismissal with a written reason is unambiguously better evidence than one without — which is all it claims.
KSI-PIY-RSD is the only indicator that reaches this control. Its statement is about the effectiveness of building security into the SDLC being PERSISTENTLY REVIEWED, and the review is a human act on a schedule; what this recipe supplies is the material that review reads and the evidence that the material is current.