SA-15 (03) Criticality Analysissa-15.3
Whether an AWS call fetches evidence for this control, and what to run. Its Rev5 baselines, the indicators that reach it and the FedRAMP guidance attached to it open below.
Nothing names itNo recipe names SA-15 (03). 8 reach an indicator it shares, which is adjacency and not coverage — worth reading, not worth recording as evidence for this control.
Collect evidence (0)
Authored AWS and pipeline recipes whose output is evidence for SA-15 (03). This mapping is this project’s opinion (AWS overlay v3.0.0, pipeline overlay v0.8.0), versioned separately from the dataset — the upstream FedRAMP rules name none of these tools.
No authored recipe names SA-15 (03). The nearest authored work is below.
The control asks the developer to perform a criticality analysis at defined decision points and at a defined level of rigor. No pipeline emits one: the analysis names which components are critical to mission function, which is a judgement about the mission rather than a property of the build. A dependency graph enumerates components and ranks none of them. A 3PAO reads the criticality analysis itself and the decision points recorded in the SDLC documentation.
This project’s assessment (automation register v0.9.0, reviewed 2026-08-13), versioned separately from the dataset and from the evidence overlays. It is an opinion about the pipeline surface on that date, and the surface moves.
The KSI that reaches it is KSI-SCR-MIT — which is what asks for it. The evidence it asks for is written, not fetched. Browse /collect for the whole authored corpus.
Reaches the same indicator, not SA-15 (03)
These recipes prove a KSI that reaches it. None of them claims SA-15 (03) — treat them as neighbours worth reading, not as coverage.
- Cryptographic proof that the audit trail CloudTrail delivered has not been altered or deleted, plus the compliance state of the write-once controls that make stored records and container images tamper-evident via KSI-SCR-MITaws
- The machine-generated inventory of every resource an external entity can reach — IAM Access Analyzer's active ExternalAccess findings — read against the declared zone of trust, so the terms-and-conditions review has a list to work from rather than a memory via KSI-SCR-MITaws
- Whether the tooling that examines acquired software is switched on and covering the estate, and what it found: Inspector's per-account enablement state for each scanned resource type, the registry-wide ECR scanning configuration (scan type and frequency, and the repository filters that decide which repositories it applies to), Inspector's own coverage statistics, and a CycloneDX 1.4 or SPDX 2.3 SBOM exported per monitored resource — the component-level inventory of what was actually acquired. via KSI-SCR-MITaws
- Whether Dependabot alerting is configured in this organization and which repositories it actually reaches, together with the alerts themselves — each carrying the advisory that raised it, the package, ecosystem and manifest path it was found in, the reason a human gave for closing it, and, for a remediated one, the date it was fixed. The first half is the population; the second half is what was found in it, and the second half means nothing without the first. via KSI-SCR-MITpipeline
- 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. via KSI-SCR-MITpipeline
What NIST requires of SA-15 (03)
The control statement from NIST 800-53 Rev5, verbatim. Square brackets are organization-defined parameters — yours to set, not FedRAMP's to dictate.
Require the developer of the system, system component, or system service to perform a criticality analysis: (a) At the following decision points in the system development life cycle: [decision points]; and (b) At the following level of rigor: [organization-defined breadth and depth of criticality analysis].
NIST SP 800-53 Rev5 catalog 5.2.0, from usnistgov/oscal-content at 78650f0. The FedRAMP dataset carries no control text; this is borrowed and pinned.
Rev5 baseline membership
Membership is the whole relationship — a baseline is a set of control ids. Class A carries no baseline at all. The Low/Moderate/High labels are an interpretation from control counts, not a dataset fact.
KSI indicators reaching this control (1)
Under 20x, these indicators are how this control is demonstrated — automated KSI evidence stands in for narrative control evidence.
Pages exist for the 209 controls reached by at least one KSI. Baseline-only controls are the orphans on /coverage. Control titles and full text live in the NIST catalog, not this dataset.