Remediation

Move from understanding a security finding to determining how it can be fixed.

A useful security finding should answer more than “what is wrong?” It should also help answer: what should change, what could that change affect, and how can the result be verified?

Securitain remediation is designed around guided, customer-controlled remediation.

Where to find Remediation

The current product page is named Remediations. It contains proposed fixes associated with supported IAM and security findings.

What remediation can contain

Depending on the finding, remediation guidance can include:

Explanation

What should change and why.

Manual steps

A human-readable sequence for applying the change.

AWS CLI guidance

A command or command direction that can be reviewed and executed in the customer environment.

Terraform guidance

Infrastructure-as-code direction where supported.

Impact context

Information that helps the operator understand what access or workflow could be affected.

Rollback context

Guidance for reversing a change when appropriate. Not every finding needs every remediation format.

Securitain does not automatically write to AWS

The current remediation workflow:

Detects finding
      ↓
Builds remediation guidance
      ↓
Human reviews / approves
      ↓
Returns CLI / Terraform / manual direction
      ↓
Customer executes change

Why remediation is customer-controlled

Security fixes can have operational consequences. For example, narrowing an IAM permission can affect application execution, deployment pipelines, support workflows, emergency access and cross-account integrations. A remediation engine should therefore help the team understand the change without silently modifying production access.

Approval is not remediation

A remediation record can be reviewed or approved. That does not mean the AWS condition is gone.

Recommendation approved
        ≠
AWS changed
        ≠
Finding verified remediated

Apply (manual guidance)

The current product action is explicitly named Apply (manual guidance). This wording is intentional — it returns the remediation material for a human or operator to execute. It should never be represented as Securitain having applied the AWS fix.

Example: broad IAM permission

Suppose a role has permission broader than required. A remediation may recommend narrowing action scope, narrowing resources, adding a condition or replacing a broad policy with a more constrained one. Guidance might include an AWS CLI or Terraform example. However, the operator should still:

• review dependent workloads
• test the change
• deploy through the organization's normal change process
• request verification after the change

Example: cross-account trust

Suppose a role trusts an external principal that is no longer required. Remediation might involve narrowing or removing the trust. Before applying the change:

• confirm the external account owner
• confirm whether a vendor or workload still uses it
• preserve the existing trust policy for rollback
• coordinate any production change

This is why Securitain includes impact and rollback context where supported.

Example: federation trust

A federation finding may indicate that OIDC or SAML trust is broader than expected. Changing identity-provider trust can lock users or CI/CD workflows out of AWS.

Review trust
    ↓
Identify approved identities / workloads
    ↓
Narrow condition
    ↓
Test
    ↓
Deploy
    ↓
Verify

Remediation risk reduction

The current Remediations view can display a risk-reduction indicator. Use it as a prioritization aid — not as a guaranteed numeric improvement, exact percentage, or compliance score.

Impact level

Impact level helps remind the operator that a security change can affect legitimate workloads. Before applying, review production criticality, workload ownership, downstream dependencies, deployment windows and rollback plan. Remediation should improve security without creating unplanned outages.

Remediation vs Finding status

Remediation record

Represents the proposed security change and guidance.

Finding status

Represents the lifecycle state of the technical condition.

Verification after remediation

After the customer applies the change, return to the finding and choose Request Verification. The finding moves into Pending Verification. The next successful capable scan determines whether the original condition still exists.

Finding
   ↓
Customer applies fix
   ↓
Request Verification
   ↓
Pending Verification
   ↓
Successful capable scan
   ├── condition absent → Remediated
   └── condition present → Open

How to use the remediation workflow

1. 1

   Open the finding

   Review severity, affected entity, evidence and related risk context.

2. 2

   Review remediation

   Understand what change is recommended and why.

3. 3

   Review impact

   Identify applications, roles or integrations that may depend on the access.

4. 4

   Approve the remediation where required

   Record the human decision to proceed.

5. 5

   Retrieve the manual guidance

   Use CLI, Terraform or manual steps as appropriate.

6. 6

   Execute through your normal change process

   Apply the change from your own controlled environment — not through Securitain.

7. 7

   Test

   Confirm legitimate workloads still work after the change.

8. 8

   Request Verification

   Return the finding to Securitain for scan-based validation. See Findings & Finding Lifecycle for the full verification flow.

Remediation and change management

Securitain remediation should fit into existing organizational processes such as pull requests, Terraform pipelines, change tickets, production releases and security engineering workflows. The documentation does not imply that Securitain replaces those systems.

Evidence and limitations

Remediation guidance is based on the finding and evidence available to Securitain. Actual production impact can depend on runtime behavior, undocumented dependencies, external systems, service-specific behavior and deployment architecture.

Related guides