The machine-maintained component inventory — Config's recorder status and discovered-resource counts proving supported resources are tracked continuously and the list stays current without anyone editing a spreadsheet, plus Systems Manager Inventory's node and installed-application metadata for what runs inside them
The API supplies the facts, but a human judgement against a documented baseline turns them into evidence.
Fetch
$ aws configservice describe-configuration-recorder-status --query 'ConfigurationRecordersStatus[].{Name:name,Recording:recording,LastStatus:lastStatus,LastStart:lastStartTime,Error:lastErrorMessage}'$ aws configservice get-discovered-resource-counts$ aws configservice select-resource-config --expression "SELECT resourceId, resourceType, awsRegion WHERE resourceType = 'AWS::EC2::Instance'"$ aws ssm get-inventory --aggregators Expression=AWS:InstanceInformation.PlatformType$ aws ssm list-inventory-entries --instance-id i-0123456789abcdef0 --type-name AWS:ApplicationExpected output
A recorder status with recording true and lastStatus SUCCESS — read this first, because a stopped or failing recorder makes everything below stale — then a resourceCounts array giving a count per resourceType alongside totalDiscoveredResources, a Results list naming each recorded resource of the type you queried, an aggregation of managed nodes grouped by platform, and an Entries list of installed applications stamped with the CaptureTime they were collected.
Map — what it proves
- recipe3
- recipe— an authored recipe collects evidence for this control
- KSI only— a Key Security Indicator reaches it, but no recipe is authored yet
- orphan— no Key Security Indicator reaches it — a person writes it up instead
What else these families can fetch:CM 14/34 →
Submits toward
- A machine readable output containing all required data of the components of the cloud service offering that are likely to handle federal customer data or likely to impact the confidentiality, integrity, or availability of federal customer data handled by the cloud service offering.
- A human readable explanation of how the machine readable output is derived.
- The code for the automated process used to generate the machine readable output.
This recipe’s output is the machine-readable half. The human readable derivation and the collector’s own code are artifacts you still owe — the rule demands all three.
GovCloud
AWS Config and Systems Manager Inventory are available in AWS GovCloud (US-East) and (US-West); resource and node ARNs use partition arn:aws-us-gov
Notes & assertions
This proves the inventory is machine-maintained and current (CM-08.01, and the automated-currency half of CM-02.02) — it does not prove the inventory is complete. Config sees only supported resource types, only in the regions and accounts where a recorder runs, and only within the recording group you configured; unsupported types, an un-recorded region, on-premises hosts, SaaS components and in-container software are invisible here and need their own source. SSM Inventory covers only managed nodes with a running agent and an inventory association, collects no more often than every 30 minutes, and the console's Inventory cards hide stopped and terminated nodes even though the API still returns them. The accountability attributes CM-08 asks for — system owner, function, criticality — live in your tags or CMDB, not in a resource count, so join them before calling this an inventory. Substitute your real instance id. Detecting unauthorized components (CM-08.03) is a different question; the prohibited-software half is in the least-functionality recipe.
References
- AWS CLI: configservice describe-configuration-recorder-status https://docs.aws.amazon.com/cli/latest/reference/configservice/describe-configuration-recorder-status.html
- AWS CLI: configservice get-discovered-resource-counts https://docs.aws.amazon.com/cli/latest/reference/configservice/get-discovered-resource-counts.html
- AWS CLI: configservice select-resource-config https://docs.aws.amazon.com/cli/latest/reference/configservice/select-resource-config.html
- AWS Config advanced query: SELECT query components https://docs.aws.amazon.com/config/latest/developerguide/query-components.html
- AWS Systems Manager Inventory https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-inventory.html
- AWS CLI: ssm get-inventory https://docs.aws.amazon.com/cli/latest/reference/ssm/get-inventory.html
- AWS CLI: ssm list-inventory-entries https://docs.aws.amazon.com/cli/latest/reference/ssm/list-inventory-entries.html
This AWS mapping is authored opinion (overlay v3.0.0), versioned separately from the dataset and written against ruleset 2026.07.14.01. The upstream FedRAMP dataset names none of these tools.
The Policy and Inventory run (4)
- automatable
- partial — needs judgement
- narrative — no API proves this
Every authored recipe filed under PIY, in the order the plan works them. The mark says how much of the evidence the command produces on its own.
- partialThe machine-maintained component inventory — Config's recorder status and discovered-resource counts proving supported resources are tracked continuously and the list stays current without anyone editing a spreadsheet, plus Systems Manager Inventory's node and installed-application metadata for what runs inside themyou are heredailyconfig-asset-inventoryAWS Config · AWS Systems Manager Inventory
- partialA Region-by-Region inventory of the resources that can hold information, the classification tags you asserted on them, and — where Macie exists — a sampled machine judgement about which S3 buckets actually contain sensitive datamonthlyinformation-location-and-classificationAWS Config · AWS Resource Groups Tagging API · Amazon Macie · Amazon S3
- 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.continuousinfrastructure-policy-scan-coverage-and-deviationsCheckov · GitHub code scanning
- partialFor a service that ships code to a browser, the two things a pipeline can say about the mobile code it delivers: what was allowed INTO it, and whether what shipped is what this pipeline built. The first is the dependency diff for the change — every component added, its ecosystem, its version, its licence and any advisory against it, separated by whether it reaches the runtime or stops at the build — and the gate that makes the check mandatory rather than advisory. The second is a provenance attestation over the built bundle, verified against the repository and workflow that are supposed to have produced it. Neither is a statement about which mobile code technologies the organization decided to permit, and that is the control's first limb.on-changemobile-code-admission-and-bundle-provenanceGitHub dependency review · GitHub artifact attestations · GitHub repository rulesets