GitHub code scanning
What this tool proves, in the authored overlay. Every recipe below names GitHub code scanning; the controls are what their output is evidence for. The mapping is this project’s opinion (overlay v0.8.0) — the upstream FedRAMP rules name no vendor and no product.
Recipes calling GitHub code scanning (4)
- partialstatic-analysis-coverage-and-flaw-dispositioncontinuous
Whether static analysis is configured in this organization and which repositories it actually reaches; for each of those repositories, which query suite ran over which languages, whether the recurring schedule is still alive, when the analysis last ran and with how many rules in the run; and what the analysis found, split into what is still open and what a person closed by hand — each closure carrying who closed it, which of four fixed reasons they chose, and whatever they wrote down. The first two halves are the population and the proof that testing happened; the third is the half an assessment asks for, and read without the other two it cannot be told apart from the output of a scanner that never ran.
- partialinput-validation-taint-analysis-coveragecontinuous
Which taint-tracking ruleset actually ran over this repository — the query suite, the languages selected, and the threat model that decides what counts as an untrusted source — together with whether the recurring scan is still scheduled, when it last ran per analysed language, and how many rules were in the run; and then the open findings in the injection families SI-10 is about, identified by the CWE tags the queries carry. The ruleset and the freshness are the load-bearing half: a finding names a sink that exists, but only the run record says the absence of findings means anything at all.
- partialerror-handling-information-exposure-scanningcontinuous
Whether the queries that find information disclosure through an error message or a stack trace ran over this part of the boundary — which languages were selected, whether the recurring scan is still scheduled and when it last completed — and then the open findings those queries produced, identified by the CWE tags the queries carry rather than by their names. The run record is the load-bearing half here as it is on every scanning recipe: a finding names a leak that exists, and only the record of a scan having run over a selected language makes the absence of findings a statement about anything.
- partialinfrastructure-policy-scan-coverage-and-deviationscontinuous
Which 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.
Controls it carries evidence for (4)
The reverse of the join above. A mark here is the control’s own grade across the whole corpus, not its grade from this tool alone — a control this tool partly proves may be fully proved with another.
Tool names are canonical, from data/overlays/aws-services.json and data/overlays/pipeline-tools.json. The two overlays that name services spelled five of them two ways; a page keyed on the raw string would have split those in half.