The Principle of Least Privilege (PoLP) is a foundational concept in both cybersecurity and DevSecOps. It means that every user, service, or system should have the minimum level of access necessary to perform its job, and nothing more.
By limiting access, you reduce the blast radius of mistakes, misconfigurations, and malicious activity. It’s not just a best practice; it’s a security baseline.
Why Is Least Privilege So Important?
- Prevents lateral movement: If an attacker compromises one account, they can’t pivot into unrelated systems.
- Protects sensitive data: Systems only see what they need. Secrets and credentials stay hidden from unqualified access.
- Reduces insider threats: Even well-meaning engineers can’t break what they can’t touch.
- Supports compliance: SOC 2, ISO 27001, and HIPAA all mandate strict access controls.
Real-World DevSecOps Example
Consider a CI/CD pipeline with permissions to deploy infrastructure via Terraform. One misconfigured GitHub Actions token had access to iam:CreatePolicy across multiple accounts.
When a contributor opened a PR with a malicious module, the pipeline executed it and granted wide-open permissions to a rogue principal. The least privilege principle would have prevented this by tightly scoping the token to only allow deployment in one environment.
How to Apply Least Privilege in DevSecOps
- Start with deny-all: Only explicitly allowed actions should be permitted.
- Scope IAM policies to services or environments: No cross-account or wildcard permissions without justification.
- Use automation: Tools like Terraform, Open Policy Agent (OPA), and AWS IAM Access Analyzer help enforce strict access boundaries.
- Monitor access logs: Regularly review which roles are being used, and trim excessive access.
- Establish review cadences: All permissions should have owners, expiration dates, and periodic audits.
What Least Privilege Looks Like
| Bad | Better |
|---|---|
iam:* for developers | iam:PassRole scoped to a specific role only in dev |
| Long-lived keys on engineer laptops | Short-lived session tokens via IAM Identity Center or OIDC |
| One shared “admin” role across all apps | Service-specific roles with scoped policies |
How to Get Started
You don’t have to refactor your entire environment overnight. Start small:
- Pick one high-risk role and break it up
- Enable IAM Access Analyzer and review the findings weekly
- Set up OPA policies to prevent new wildcard roles from being merged
- Track access changes via audit logs (e.g. AWS CloudTrail)
Further Reading
Want to see how StackProof handles least privilege with automation? Check out our GitHub Actions + OIDC + Terraform playbook next.