IntermediateCloud Security

Use short-lived credentials via OIDC for CI/CD pipelines instead of long-lived secrets

Long-lived AWS access keys, GitHub personal access tokens, and API secrets stored in CI/CD environment variables are stolen regularly. The Codecov bash uploader attack harvested environment variables from thousands of build pipelines. The GitHub/Heroku OAuth token theft gave attackers access to private repositories. OpenID Connect (OIDC) enables CI/CD systems to request short-lived, scoped credentials from AWS, GCP, and Azure for each specific pipeline run — with no static secret stored anywhere. A stolen OIDC token is valid for minutes, not months. GitHub Actions, CircleCI, and most major CI platforms support OIDC-based credential exchange.

More in Cloud Security

All guides

intermediatefeatured

Apply least-privilege IAM policies — no wildcard permissions in production

AWS IAM wildcard policies (Action: "*", Resource: "*") are the cloud equivalent of giving every employee a master key to every door. The Capital One breach was enabled by an SSRF vulnerability that allowed the attacker to query the EC2 metadata endpoint and retrieve IAM role credentials — credentials that had far broader permissions than the application needed. The GoDaddy breach used a provisioning system credential to access data across 1.2 million customer accounts. Audit every IAM role for over-broad permissions. Use AWS IAM Access Analyzer or equivalent tools to identify unused permissions. Restrict each role to exactly the S3 buckets, EC2 instances, and services it requires for its specific function.

See: Capital One BreachCloud Security

beginner

Block public access on S3 buckets at the account level, not just the bucket level

Misconfigured S3 buckets containing sensitive data have been a consistent cloud security failure for a decade. The fix exists: AWS S3 Block Public Access can be enforced at the account level, preventing any bucket in the account from ever being made public regardless of bucket-level settings. Enable Block Public Access at the organisation level in AWS Organizations SCPs. For buckets that legitimately need public access (static website hosting), require explicit approval and documentation. Audit all existing buckets for public access using AWS Config rules. Capital One's breach involved a misconfigured WAF role that could list and access S3 buckets — public access controls would not have stopped it, but defence in depth would have.

See: Capital One BreachCloud Security

beginner

Enable CloudTrail, VPC Flow Logs, and GuardDuty as a minimum baseline

You cannot detect or investigate a cloud breach without logging. The three minimum logging controls in AWS are: CloudTrail (API call audit log — who did what, when, from where), VPC Flow Logs (network connection records — which IPs connected to which IPs), and GuardDuty (threat detection service that analyses CloudTrail and flow logs for anomalies). These three together provide the visibility needed to detect credential misuse, unusual API calls, and lateral movement. Enable them in every account in your AWS Organization from day one. Store CloudTrail logs in a separate security account that production accounts cannot delete.

See: Capital One BreachCloud Security