AWS Config

regscale aws sync_config_compliance reads the results of your AWS Config rules and records them in RegScale as control assessments for a security plan.

Command syntax

regscale aws sync_config_compliance [OPTIONS]

Basic usage

Sync the AWS Config results for a security plan:

regscale aws sync_config_compliance --regscale-id 123

Limit the sync to Config rules that have specific tags. A run with --tags records no control assessments. See What a scoped run closes.

regscale aws sync_config_compliance --regscale-id 123 --tags Environment=Production

What the command creates

• Control assessments with a pass or fail result.
• Issues for failed controls. The command creates issues by default. Use --no-create-issues to turn this off.
• Updates to the control implementation status. Use --no-update-control-status to turn this off.
• Evidence. Add --collect-evidence to turn this on.

Common use cases

Daily compliance monitoring:

regscale aws sync_config_compliance --regscale-id 123 --create-issues

Compliance for one account in a multi-account organization. A run with --account-id or --tags records no control assessments:

regscale aws sync_config_compliance --regscale-id 123 --account-id 123456789012 --tags Environment=Production

Evidence collection

Add --collect-evidence to store evidence from the AWS Config evaluations.

regscale aws sync_config_compliance --regscale-id 123 --collect-evidence --evidence-control-ids AC-2,AU-3,SI-2

Filtering

A run that uses one of these options works from only the matching Config rules, so it judges a control from part of its rules.

A run with --offset and --limit reads all of your AWS Config data, the same as a run without them. It then processes only the controls in its slice. See What a scoped run closes.

What a scoped run closes

A run without a scope option closes the findings and issues of controls that pass in this run. A scoped run closes fewer of them, or none, as this table shows.

--offset and --limit slice controls, not rules. A control's records close only if the control is in the slice. If two controls come from the same rule and only one is in the slice, the other control's records stay open.

A run that records no control assessments also does not change control implementation statuses. It logs Not updating control assessments or implementation statuses: this run is scoped by and the option names. To assess the controls, or to close the findings that a scoped run leaves open, run the command for the plan without a scope option.

A --conformance-pack-name run closes no findings or issues of controls that pass. If you schedule only pack runs, also schedule an unscoped run of the command for the plan, or records never close.

A run also cleans up records that an earlier build stored under the bare AWS account ID. The key of such a record is aws config-<control>-<account id>, for example aws config-AC-2-111122223333. This is key migration cleanup. It is not the closing of a passing control, and it does not depend on the scope option. Only a run that creates issues does it, and only for a control that fails in that run. The run logs Closing N stored record(s) keyed by an account id this release replaced. What happens to the issue that the earlier build stored depends on your RegScale version.

• Below RegScale 6.36.0.0. The run closes the old finding with the note Superseded, not remediated:. It does not close the old issue. That issue stays Open and keeps the source "Scanner Integration". The platform adds a Closed copy of it under the old key, with the source "AWS Config" and without the note. The platform also opens a new issue under the current key. So a failing control has two open issues, the old one from 6.x and the new one. The CLI does not close the old one. A later unscoped run in which every rule passes closes the new issue and leaves the old issue Open. Unscoped, pack, --tags and slice runs all do this. Close the old issues yourself. They are the open issues whose key has the account id straight after the control and whose source is "Scanner Integration".
• RegScale 6.36.0.0 and later. These versions adopt the issues that earlier builds stored. For a plan that holds only the old records, the run closes nothing and creates no issue under the current key. The platform updates each old record. The record keeps its old key and stays Open, and its source changes from "Scanner Integration" to "AWS Config". A second run keeps the old keys. If a 7.0 run on a platform below 6.36.0.0 already added the Closed copy, a later run on 6.36.0.0 or later still leaves the old issue Open and logs no closing line.

Sync one conformance pack

regscale aws sync_config_compliance --regscale-id 123 --conformance-pack-name nist80053r5

If AWS does not know the pack name, the run stops and names the pack.

Security Hub compliance data

sync_config_compliance reads AWS Config only. To record compliance data from AWS Security Hub, use regscale aws sync_securityhub_compliance.

The --use-security-hub and --no-use-security-hub options are deprecated in CLI 7.0.0, and their removal is planned for 8.0.0. They never read Security Hub, so they change nothing: a run with one of them creates the same assessments and returns the same exit code as a run without it. The command still accepts them, so existing scripts continue to work. It hides them from --help and writes a deprecation warning to stderr that names regscale aws sync_securityhub_compliance. Remove the option from your scripts.

Command options

Best practices

1. Turn on AWS Config in all regions that have resources.
2. Tag your Config rules to mark the compliance boundary.
3. Schedule a daily sync for continuous monitoring.
4. Use regscale aws sync_securityhub_compliance for Security Hub compliance data, and regscale aws sync_compliance for AWS Audit Manager.