Containers and serverless functions are not magic. They have their own security profile, and their own classes of failure.
Containers
- Image hygiene. Pin base images, scan them, rebuild on a cadence — vulnerabilities in the base accrue over time
- Runtime privilege. Containers should not run as root; the container runtime should not have access to the host's filesystem or socket unless absolutely required
- Secrets handling. Never bake secrets into the image; mount them at runtime from a secrets manager
Serverless functions
- Cold-start identity. Each function execution starts with the role attached; over-permissive roles compound across thousands of executions
- Dependency footprint. A function with a hundred dependencies has a hundred attack surfaces; minimize ruthlessly
- Event sources. A function triggered by a public-facing event source is publicly addressable even if the function itself is not "exposed" — validate every input
Patterns that fail
- One huge container image used for everything because "Dockerfile reuse"
- Functions with
*resource permissions because "we'll narrow it down later" - Build pipelines that pull from upstream registries on every build with no version pinning
Patterns that work
- Distroless or minimal base images, version-pinned, scanned in CI
- Per-function roles scoped to the exact actions and resources used
- A registry of approved base images and a process for updating them
- Vulnerability triage SLAs based on severity and reachability
Takeaway
Containers and serverless raise the bar on what you can do quickly. They do not raise the bar on what is automatically secure. The defaults are a starting point, not a destination.
HS Academy
All HS Academy lessons are free to read. Create a free HorizonShield account to explore the platform itself.
Sign up free →