Developers hold the key to cloud security because most cloud risk is created in code: infrastructure templates, IAM policies, service credentials and application logic. A security team that reviews the account afterward is always late. Safe defaults and feedback inside the developer workflow fix problems at the point they are introduced.
What do developers actually decide?
In a cloud account, a handful of everyday developer choices set the exposure:
- Which identity a workload runs as, and what that identity may do.
- Whether a storage bucket or database is reachable from the internet.
- How an application gets its credentials: temporary role credentials or a long-lived key pasted into a config file.
- Which packages and base images ship in the artifact.
None of those are decided by a firewall team. They are decided in a pull request, usually on a deadline.
What does the AWS guidance say?
AWS's IAM best practices page is blunt about credentials. It tells you to require workloads to use temporary credentials through IAM roles, and to require human users to reach AWS through federation with an identity provider so they also receive temporary credentials. It says that for workloads on AWS compute services such as EC2 or Lambda, the platform delivers role credentials to the code, so there is no need to distribute long-lived credentials for an IAM user to your workloads.
Read that as a developer instruction. The secure path is also the easy path: attach a role, let the SDK find the credentials, and never write a key into the repository. The page also recommends applying least-privilege permissions, starting from managed policies and tightening them based on access activity, and removing unused users, roles and permissions on a schedule.
Why does shifting responsibility to developers work?
NIST's Secure Software Development Framework, SP 800-218, exists because few development lifecycle models address security in detail, so secure practices have to be added to each one. Its aim is to reduce vulnerabilities in released software, limit the impact of those left undetected, and address root causes to prevent recurrence. That last phrase matters. Fixing a misconfigured resource once helps once; fixing the template that produced it helps every time.
CISA's Secure by Design guidance, co-sealed by CISA and international partners, pushes the same direction from the vendor side. It describes three principles: take ownership of customer security outcomes, embrace radical transparency and accountability, and lead from the top. The third principle is a reminder that developers cannot carry this alone; leadership must make secure choices the default and fund the time to use them.
What goes wrong when security sits outside the workflow?
Constructed example. A team ships a service with an IAM policy that allows all actions on all resources, because a narrow policy kept failing in testing and the release was due. A later account review flags it three months after launch. By then, other services depend on it, nobody remembers the original failure, and tightening the policy risks an outage. The cheapest moment to fix it was the pull request.
How to check or apply this
- Make the secure option the default. Provide infrastructure modules with private storage, encryption and least-privilege roles already set.
- Ban long-lived access keys in code. Use roles, and scan repositories for secrets.
- Check infrastructure templates and policies in the pull request, not after deployment.
- Scan dependencies and base images in CI, and prioritize findings that are reachable in your code.
- Review IAM permissions on a schedule and remove what is unused.
- Give developers a named security contact and a fast answer when a policy blocks them.
Safeguard fits at steps 2 and 4. Its dependency scanning, reachability analysis and policy gates can run where developers already work, in the CLI, IDE extensions and pull request checks, and its free in-browser scan at gold.safeguard.sh/scan covers up to 100 dependencies.
Quick check
Does this mean developers own all cloud security?
No. Security teams still set policy, monitor accounts and respond to incidents. The point is that developers make the changes that create risk, so controls must reach them early.
What is the single most useful change for a team starting out?
Replace long-lived credentials with temporary role credentials. It removes a whole class of leaked-key incidents and, per AWS guidance, is the recommended pattern for workloads.
Sources
- AWS IAM, Security best practices
- NIST SP 800-218, Secure Software Development Framework
- CISA, Secure by Design
Last reviewed: 18 October 2026.
