DevSecOps & Security Basics 2026 - Shift-Left Security and Kubernetes Protection

In modern DevOps, security is not a final gate - it is built in from the first commit. That practice is DevSecOps.

What is DevSecOps?

DevSecOps integrates security into the DevOps pipeline from the start, so vulnerabilities are caught during development and CI/CD rather than after release.

Why shift-left?

"Shift-left" means moving security earlier in the lifecycle. Fixing a vulnerability in code review costs a fraction of fixing it in production - earlier is cheaper, faster and safer.

There is a second reason that matters more day to day: a finding raised while the developer still has the code in their head gets fixed in minutes. The same finding raised six weeks later by a quarterly scan becomes a ticket, then a backlog item, then an exception.

The four kinds of scanning, and what each catches

These get used interchangeably in job descriptions and they are not the same thing. Knowing which is which is a common interview separator.

Type	What it looks at	Catches	Tools
SAST	Your source code, without running it	Injection flaws, unsafe patterns	SonarQube, Semgrep
SCA	Your dependencies	Known CVEs in libraries you pulled in	Snyk, Dependabot
Container scan	The built image, layer by layer	Vulnerable OS packages in the base image	Trivy, Grype
DAST	The running application	Issues only visible at runtime	OWASP ZAP

Most vulnerabilities in a typical service are not in code the team wrote - they are in the dependency tree and the base image. That is why SCA and container scanning usually deliver more than SAST in the first year of a security programme.

Common DevSecOps tools

• Trivy: scans container images for known vulnerabilities.
• SonarQube: static code analysis for bugs and security issues.
• Snyk: finds and fixes vulnerabilities in dependencies.

These run automatically in CI/CD so insecure code never reaches production unchecked.

Wiring a scan into a pipeline

An image scan as a GitHub Actions step, failing the build on high-severity findings:

- name: Scan image
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: myapp:1.2.0
    format: table
    exit-code: '1'
    severity: HIGH,CRITICAL
    ignore-unfixed: true

Two of those options are the difference between a gate people respect and one they route around. exit-code: 1 makes the scan actually fail the build rather than print a wall of text nobody reads. ignore-unfixed: true suppresses findings with no available patch - without it the first run reports hundreds of unfixable issues, the team concludes the tool is noise, and the gate gets disabled within a fortnight.

Start by failing only on CRITICAL, get the count to zero, then tighten to HIGH. A gate that is on and narrow beats a gate that is broad and switched off.

Secrets are the failure that actually happens

Most real incidents at small companies are not exotic exploits. They are a cloud key committed to a repository. Three habits prevent nearly all of it:

• Scan for secrets before the commit lands - gitleaks or the platform's own push protection.
• Assume any leaked key is burned. Deleting the commit does not help; the value is in the history and probably in someone's clone. Rotate it.
• Prefer short-lived credentials. A CI job that assumes a role gets credentials that expire. A stored access key does not.

Kubernetes security basics

Containers and Kubernetes need their own protections:

• RBAC: role-based access control - grant least privilege to users and services.
• Secrets management: never bake passwords or keys into images; use Kubernetes Secrets or a vault.
• Network policies: restrict which pods can talk to which - default-deny, then allow only what is needed.
• Image scanning: only deploy trusted, scanned images from a known registry.
• Pod security: avoid running containers as root and limit their capabilities.

The pod-level settings that do the most work, and cost nothing to add:

securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop: ["ALL"]

One caveat worth knowing before you apply it: readOnlyRootFilesystem breaks applications that write temporary files, which is more of them than you would expect. The fix is a writable emptyDir volume mounted at the path it needs, not turning the setting off.

A note on Kubernetes Secrets specifically: by default they are base64-encoded, not encrypted. Anyone with read access to the namespace can decode them. Enable encryption at rest, or use an external secrets store, and do not assume the name means more than it does.

The mindset

Security is everyone's job in DevOps. Automating scans and applying least privilege everywhere is what keeps fast-moving systems safe.

The practical version: make the secure path the easy path. A template repository with scanning already wired in and a base image that is already hardened will do more for an organisation's security than any amount of policy documentation.