Secure an AWS Delivery Workflow with Gates, Secrets, and Policy

Table of Contents

1. Challenge

   Configure pipeline identity and secret access for the delivery workflow

   Secure the inherited workflow's identity and secret handling without breaking delivery:

   1. Replace wildcard IAM permissions with supplied least-privilege policies.
   2. Move the plaintext deployment token into AWS Secrets Manager and configure CodeBuild to retrieve it at runtime.
   3. Verify the secured pipeline still builds and deploys successfully without exposing the secret.
2. Challenge

   Add security checks for dependencies and images

   Create and test two security checks against the inherited application:

   1. Configure an OWASP Dependency-Check gate to identify vulnerable application dependencies.
   2. Configure an Amazon ECR Basic image-scan gate to evaluate container image findings.
   3. Run both gates independently and confirm that they produce verdicts and preserve their reports.
3. Challenge

   Use gate results to block or continue promotion

   Use security-gate results to control whether a release can reach deployment:

   1. Add a Security stage before Deploy and configure both gates to run in parallel.
   2. Run the vulnerable application through the controlled pipeline and interpret the gate results.
   3. Confirm that the failing dependency gate blocks the new execution before it reaches Deploy.
4. Challenge

   Remediate the failing dependency check and rerun the controlled workflow

   Repair the vulnerability that caused the security gate to fail:

   1. Interpret the dependency report and identify the vulnerable commons-text version.
   2. Upgrade the dependency from 1.9 to 1.10.0 and release the updated source.
   3. Confirm that both gates pass and the repaired execution continues successfully to Deploy.
5. Challenge

   Verify that the workflow preserves useful security and release evidence

   Trace the blocked and successful releases through their preserved evidence:

   1. Identify the pipeline execution IDs for the blocked and repaired releases.
   2. Compare their scan reports in Amazon S3 and their build logs in CloudWatch Logs.
   3. Confirm that the evidence explains why one release was stopped and the other was allowed to deploy.