
Tech • AI • Robotics
A compact shift-left security pipeline on AWS can block vulnerable container builds before deployment by linting the Dockerfile, scanning the built image, and sending automatic email alerts.
Finding a security flaw while code is still being written is far cheaper than fixing it after release. The same bug can escalate from a quick code change to an incident response, emergency patching, or even a public breach once it reaches production. The core principle is to move security checks as far left in the software lifecycle as possible.
The design inspects both the container recipe and the finished image on every build. Hadolint reviews the Dockerfile for weak practices, while Trivy scans the built container for known CVEs. If high or critical vulnerabilities are found, the pipeline fails immediately and prevents deployment.
The automation server is given AWS permissions through an IAM role rather than long-lived access keys stored on disk. That role grants only what is needed: the ability to publish notifications and to be managed through AWS’s secure management channel. This keeps credentials temporary and reduces secret leakage risk.
The environment runs inside a dedicated VPC with a single public subnet. Internet access is enabled by routing outbound traffic through an internet gateway. The attached security group starts deny-all and opens only port 80 for web access to the Jenkins interface.
A small Ubuntu EC2 instance hosts Docker, and Jenkins runs inside a container rather than directly on the machine. To let Jenkins build containers, the host’s Docker socket is mounted into the Jenkins container, giving it direct access to the underlying Docker engine. The server is managed without SSH keys, using AWS’s browser-based session access instead.
Because a small instance can struggle with image builds and vulnerability database loading, the setup adds a 2 GB swap file. That extra virtual memory helps avoid crashes when Trivy downloads and processes its vulnerability data alongside Jenkins and Docker workloads.
Alerts are sent through an Amazon SNS topic with an email subscription. When a build fails, Jenkins publishes a message and AWS distributes it to subscribers. This ensures failures are delivered directly to the team instead of waiting for someone to notice a red build in the dashboard.
The demonstration uses a deliberately insecure Nginx base image to prove the gate works. An old image version accumulates dozens of known vulnerabilities over time, making it likely to trigger Trivy’s high-severity and critical-severity thresholds. The failed build is therefore an expected and useful result, not a malfunction.
A final pipeline step runs regardless of success or failure. It combines Hadolint findings and Trivy scan results into one report and sends that summary through SNS. The notification can include the bad Dockerfile details, the exact CVEs, and the build number, giving teams immediate context for remediation.
The setup is intentionally simplified and is not presented as a hardened production environment. Jenkins is exposed over plain HTTP, authentication is disabled, and only a narrow part of a full DevSecOps program is shown. Even so, the pattern reflects a real operational model: inspect every build, block dangerous artifacts automatically, and notify people fast.
The architecture shows how a lightweight AWS pipeline can enforce shift-left security for containers with automatic checks and hard build stops. Its main value is simple: dangerous images are caught before deployment, and the team is alerted while the fix is still cheap.
Explain this