Security for DevOps: The Basics a Junior Needs

Why security comes after observability

You have touched security at each step: SSH keys, file permissions, IAM roles. Doing it now pulls those pieces into one review of a system you built yourself. You also have logs and alerts by this point, so you can see what happened if something does go wrong.

Nothing here should wait until now if you can do it sooner. Never commit a secret, even at step 1. This step checks your work and fixes the gaps.

Evidence on what employers expect from juniors in security is thin. We did not find a dataset that breaks it out, so treat this list as our judgment. It covers the failures a junior is most likely to cause or to catch.

What to learn, in order

1. Keep secrets out of Git. A secret is a password, key or token. Git keeps old versions forever, so a deleted secret is still in the history. Run gitleaks on your repo. On public repos, GitHub also runs secret scanning automatically.
2. Store secrets in a proper place. Use a secrets manager (a service that stores secrets and controls access to them). AWS Secrets Manager and Parameter Store are two options. Your app reads them when it runs, so they never sit in code or in an image.
3. Least privilege. Least privilege means giving only the access a job needs. Review each IAM role from your AWS step. Replace any * you can, because a stolen role can only do what the role allows.
4. Replace long-lived keys with OIDC. A stored key works until someone disables it. OIDC lets your pipeline get short-lived AWS access with no stored key. Limit the role's trust to your repo and branch. Copy the current format from that page, because it has changed for newer repos.
5. Close what does not need to be open. Check each security group and firewall rule. Only your load balancer should face the internet. Your database should have no public address.
6. Keep software patched. Many attacks use bugs that already have a fix. Turn on unattended-upgrades on Ubuntu servers, and rebuild images often so they pick up a fresh base image.
7. Scan in your pipeline. A scanner such as Trivy checks images and dependencies for known bugs. Fail the build on critical findings only at first. If every build fails, people will turn the scanner off.
8. Know what your pipeline trusts. Third-party actions run with access to your secrets. Pin them to a full commit SHA, because a tag can be moved to point at bad code.
9. Know the web's common failures. Read the headings of the OWASP Top 10, a list of common web app risks. 2025 is the current edition. It helps you follow along when a developer brings them up.

What to skip for now

• CISSP, CKS and Security+.
• Pen testing (attacking systems to find holes) and bug bounties.
• Compliance frameworks such as SOC 2 and PCI. Know that they exist.
• Service mesh mTLS (encrypting all traffic between services).
• Running your own Vault server. A managed secrets service does the job here.

Common mistakes

• Deleting the file and thinking the leak is over. The secret is still in the history, and it may already be copied. Disable it first, then clean up.
• Treating .env as safe by default. It is only safe if it is listed in .gitignore and was never committed. Check with git log --all -- .env.
• Mounting the Docker socket into a container. That gives the container control of the host, close to root access. The same goes for --privileged.
• Believing a clean scan means you are safe. Scanners find known bugs in packages. They do not catch an open database port or a role with too much access.
• Using a strong password as your only defense. A database open to the internet is still one mistake away from a breach. Reduce who can reach it as well.

Your project

Attack your own project. In a throwaway repo, commit a made-up key that looks real. Never use a real one. Scanners may ignore the example key from the AWS docs, so make up your own random string. Check that gitleaks catches it, then add the scan to your pipeline so the next one blocks the merge.

Then audit your real project: IAM roles, open ports, stored keys. Switch your pipeline to OIDC, if you have not already, and delete any old access keys. Write one page on what you found, what you changed, and your first-hour plan for a leak. That page gives you something real to talk about in an interview.