KSI-SVC-ASMAutomating Secret Management

The commands split cleanly across the control family, and the gap in the middle is the one to be honest about. AC-17(1) — automated monitoring and control of remote access — is what session history and connection logs deliver, with two documented blind spots. Session Manager does not log sessions that connect through port forwarding or SSH, because SSH encrypts the session data inside the TLS connection and Session Manager is only the tunnel; an operator who port-forwards leaves a session record with no command content behind it. And describe-sessions reaches back 30 days only, so anything longer is an S3 or CloudWatch Logs query against the destinations named in the preferences document, not an SSM call. Client VPN retention is shorter still — terminated connections drop out of the API after 60 minutes, which makes the log group named in ConnectionLogOptions the only durable record, and Username is populated only for Active Directory authentication, so certificate-authenticated users are identified by CommonName or not at all. AC-17(2) is the strongest link in GovCloud, where the endpoints are FIPS 140-3 modules by construction; the Session Manager equivalent is kmsKeyId in the preferences document, and it is empty unless you set it, so an empty kmsKeyId is a finding rather than a default. AC-17(3) — routing remote access through managed network access control points — is the one nothing here proves. Session Manager and a Client VPN endpoint are managed access points, and ec2-instance-no-public-ip is the closest negative check, but that rule applies only to IPv4 and only to AWS::EC2::Instance: an IPv6-reachable instance, a load balancer fronting SSH, or a third-party jump host is invisible to it. Read the result as 'no EC2 instance carries a public IPv4 address', which is a useful sentence and not the control. AC-17 itself — the documented usage restrictions, configuration requirements and per-type authorization — is a record you write, and this telemetry only shows whether the estate matches it. One warning to carry into the evidence package: Session Manager logs the commands entered and their output, so a credential typed into a session lands in the log group you are about to hand an assessor.

IA-05 (06) asks the provider to protect authenticators commensurate with the security category of the information to which use of the authenticator permits access. Two words in that sentence are the reason this is `partial` and would stay `partial` under any amount of extra collection. PROTECT is broader than DETECT: this evidence is a detection-and-response record for one storage location, and the control asks about the protection of authenticators wherever they live. COMMENSURATE is a judgement that requires knowing what the credential opens, and no field in any response here says that — `secret_type` names the kind of credential, never the security category of what it unlocks. A `high` alert on a test-fixture token and a `low` alert on a production database password are the same shape in this output. The disposition this recipe spends said exactly that, and writing the commands down has not changed it. The population problem, stated once and load-bearing everywhere below. Authenticators live in secret stores, CI variable sets, container images, build arguments, configuration management and on operator workstations. This recipe reads git repositories on one platform. The fraction of the provider's authenticator population that is in scope here is not a number this recipe can compute, and `scan_scope` names the external list against which somebody has to compute it. WHY THE VALIDITY CLAUSE IS INTERLOCKED WITH A SETTINGS CLAUSE, AND WHY THE INTERLOCK IS NECESSARY WITHOUT BEING SUFFICIENT. The fourth assertion asserts that no open alert has a `validity` of `active` — no leaked credential is confirmed to still work. Read alone it is one of the most vacuous clauses on this plane, because `validity` is `unknown` for every alert in an organization that never switched validity checks on, and `unknown` is not `active`, so the clause passes perfectly on an organization that has never checked a single credential. The third assertion exists to close that: it fails an organization whose configurations leave `secret_scanning_validity_checks` at anything other than `enabled`. What it does NOT do is make the fourth clause safe, and an earlier draft of this paragraph claimed it did. Three residues survive it. First, GitHub documents that validity checks are "available for secrets from many service providers, and support continues to expand" and that "Some secrets require more than the token itself to confirm whether they are active" — so a leaked credential of an unsupported type reports `unknown` with validity checking fully enabled, and the fourth clause passes over it. Second, GitHub "will periodically check the validity of a detected credential", which is a schedule rather than a trigger: enabling the feature does not retro-populate the alerts already open, so there is a window after enablement in which every existing alert is still `unknown`. Third, the third clause is not even the only prerequisite — the FIRST assertion is equally load-bearing, because with `secret_scanning` off there are no alerts of any validity at all and the fourth clause is vacuous for a reason the third never touches. And the third clause reads configurations rather than repositories, so it can be red while validity checking is genuinely on through repository-level settings, and green while the repositories that matter are attached to no configuration at all; it does not bind the population the alerts came from. Read the fourth clause as meaningful only when the first and third are green AND the reconciliation in `scan_scope` has been done, and read a green fourth clause on its own as saying nothing. THE PARTNER PROGRAMME IS AN INVISIBLE SUCCESS PATH AND IT MAKES AN EMPTY ALERT LIST AMBIGUOUS IN A NEW DIRECTION. GitHub states that "Partner secrets are reported directly to the provider and aren't displayed in your repository alerts". So for a leaked credential issued by a participating vendor, the platform's response is to tell the vendor, and the provider's own alert list stays empty. An empty `alerts-open` is therefore equally an organization that has leaked nothing, an organization that is not scanning, and an organization whose leaks were all handled by a party that never told it. The first and third of those are indistinguishable in this output and only one of them is a pass. This is not the usual empty-list caveat imported from the plane card; it is a documented behaviour of this specific feature, and an assessment reading a clean alert list as evidence of a clean estate has made the exact error the platform's own documentation predicts. What the bypass fields are worth, and where they stop. Push protection blocks a push containing a detected credential, and GitHub documents that anyone with write access can bypass it by choosing a reason from "It's used in tests", "It's a false positive" and "I'll fix it later", after which the platform "Creates an alert", "Adds the bypass event to the audit log", and emails owners, security managers and repository administrators. So a bypass is a recorded decision rather than a silent one, and `push_protection_bypassed`, `push_protection_bypassed_by` and `push_protection_bypassed_at` on the resulting alert are that decision as fields. No clause below asserts a count of zero over them, deliberately: a bypass is a documented, authorized action with a named actor and a stated reason, and a provider with a legitimate test fixture would fail such a clause while behaving correctly. The bypass records are collected as a record for a human to read against the provider's own procedure — the third of the three documented reasons is an admission that a credential was pushed knowingly, and how long "later" ran is a question for the assessment rather than for a threshold. Delegated bypass, whose enablement is visible as `secret_scanning_delegated_bypass`, moves the decision to a reviewer; it is collected, not asserted, for the same reason. A code security configuration is not the only way any of this gets switched on, so the first three clauses are wrong in one direction. The features can be enabled on a repository directly in its own settings, with no configuration involved, and an organization that never adopted configurations returns an empty list from the first command and fails all three while scanning everything it owns. Read a failure as "no organization-level configuration governs this" — which is literally true and is itself a finding — and NOT as "nothing is scanned". The reconciliation named in `scan_scope` is what separates the two readings, and nothing in this output does. The `target_type` narrowing carries the same cost it carries on the dependency recipe: the enum admits `global` and `enterprise`, an administrator can apply a configuration owned elsewhere, and applying it is a decision this clause will not count. The trade is made the same way and for the same reason. KSI-SVC-ASM is claimed on the PROTECTION limb only. The indicator asks for management, protection and regular ROTATION of keys, certificates and other secrets, automated and persistently reviewed. Detection of an exposed secret, and the record of what was decided about it, is protection and it is review. Rotation is not a scanning result: `resolution` admits `revoked`, which is the closest this output comes, and it is a human's assertion typed into a dropdown rather than an observation that a credential was replaced. The rotation limb of this indicator is answered on the AWS plane, by the KMS and ACM recipes, and an indicator page carrying this recipe should be read as carrying evidence for a part. KSI-IAM-APM and KSI-IAM-ELP also reach this control in the dataset and are deliberately not claimed: one is about passwordless and phishing-resistant authentication methods and the other about least privilege, and a leaked-credential detector speaks to neither.