Introduction
Our R&D organization relies heavily on Docker. Containers are how we build, test, and share ideas quickly — from small prototypes to large research workloads. Over time, though, this flexibility started to reveal a familiar pain point: security visibility just couldn’t keep up with the speed of development.
We didn’t have a central view of vulnerabilities or misconfigurations in our containers. Some images were pulled from public registries, others were built locally — and because these environments were short-lived, the usual enterprise tools weren’t a good fit.
We needed something lightweight, modular, and open-source — something we could deploy anywhere without worrying about cost or lock-in.
That’s how we ended up designing our own container security stack, built around Wazuh as the central integration and automation layer.
The Problem We Needed to Solve
Our Docker environments were evolving faster than our ability to monitor them. Containers were spun up for a few hours to test an API, run a model, or validate a build — then torn down. In that kind of setup:
- You can’t justify enterprise-grade monitoring tools that bill per node or per container.
- You can’t rely on manual scanning, because containers change daily.
- You can’t afford “after the fact” visibility — you need real-time awareness.
In short, we wanted continuous visibility without continuous cost.
We weren’t trying to replicate Wiz or Sysdig. We just wanted to cover the essentials:
- Identify vulnerable or misconfigured images before deployment.
- Monitor container behavior at runtime.
- Centralize alerts and feed them into Jira automatically.
That’s the baseline we designed for — simple, fast, and fully open-source.
The Approach
We started by listing the core layers of container security we wanted to address and then mapped open-source tools that covered each one.
| Focus Area | Tool | What It Does |
|---|---|---|
| Image vulnerabilities | Trivy | Scans images for known CVEs and OS package issues |
| Image configuration | Dockle | Checks Dockerfiles and images for bad practices (like running as root) |
| Host & daemon compliance | Docker Bench for Security | Evaluates Docker host setup against CIS benchmarks |
| Runtime activity | Falco | Watches containers for abnormal behavior via syscalls |
| Aggregation & automation | Wazuh | Central SIEM that ingests all logs, correlates findings, and automates alerting |
The Architecture
Here’s the big picture of how everything fits together:
Each component feeds into Wazuh, which acts as the “brain” of the operation:
- Trivy and Dockle run during CI/CD builds, outputting results as JSON logs.
- Docker Bench for Security runs on the host to check Docker daemon configurations.
- Falco runs continuously to detect runtime anomalies.
- All of these send their findings to Wazuh, which normalizes the data, applies custom rules, and forwards high-severity alerts directly to Jira for tracking.
From a developer’s point of view, that means you don’t have to go hunting through five dashboards. If something critical happens — a vulnerable image, a risky container configuration, or a runtime exploit attempt — it shows up as a Jira ticket with all the context you need.
Deployment Story
We rolled this out gradually, keeping things pragmatic and developer-friendly:
- Start small. We first integrated Trivy and Dockle in a couple of CI pipelines to see how much noise they generated and how developers responded to the feedback.
- Centralize. Once we had the scans working, we wired up Wazuh to collect their outputs. That gave us a single pane of glass to view vulnerabilities and misconfigurations.
- Add runtime visibility. Falco came next — installed as a lightweight daemon on a few hosts to detect real-time anomalies (like unexpected shell access or network calls).
- Automate follow-up. Finally, we added Wazuh’s Active Response hook to automatically create Jira tickets for anything critical.
Each step added value on its own, but the real power came when we tied it all together. Suddenly, we had a full feedback loop: scan → alert → ticket → resolution — all without human intervention.
Results
Within a few weeks, the difference was noticeable.
| Area | Before | After |
|---|---|---|
| Image scanning | Manual and inconsistent | Automated across all CI builds |
| Configuration hygiene | Ad hoc | Enforced via Dockle and Wazuh |
| Runtime visibility | None | Continuous monitoring with Falco |
| Alert management | Email or Slack pings | Centralized in Wazuh |
| Issue tracking | Manual follow-up | Automated Jira ticketing |
| Cost | Would have been thousands per year | Zero licensing cost |
More importantly, we finally had clarity.
We could see what was running, what was vulnerable, and whether it was compliant — all from a single dashboard.
Developer Impact
- Instant feedback: Developers see scan results early and can fix issues before pushing code.
- Less noise: Wazuh correlation rules filter out low-severity findings.
- Actionable alerts: Jira tickets include clear summaries and recommended fixes.
It made security part of the workflow — not a separate process that slows things down.
Lessons Learned
This project wasn’t about reinventing the wheel — it was about connecting the right pieces.
Here’s what stood out:
- Open source is more than “good enough.” With a bit of wiring, these tools rival commercial solutions for most container use cases.
- Automation wins hearts. Developers engage with security when it feels like part of the pipeline, not an external audit.
- Centralization is key. Wazuh brought everything together in a way that made sense to both engineers and security teams.
- Keep it lightweight. We avoided complexity by staying modular — each component can be replaced or updated independently.
What’s Next
Now that we’ve proven this works for Docker, we’re looking at extending it to:
- Our internal Kubernetes clusters, using the same tools and Wazuh as the central hub.
- SBOM (Software Bill of Materials) generation for better supply chain visibility.
- Slack and Teams integrations for quicker real-time notifications.
- Automated compliance reporting for internal security reviews.
We’re also continuing to tune the alert rules in Wazuh to balance coverage with noise reduction — the ultimate goal being “useful alerts only.”
Conclusion
By combining Wazuh with a handful of proven open-source tools — Trivy, Dockle, Falco, and Docker Bench for Security — we built a Docker security framework that fits how our teams actually work: fast, decentralized, and constantly changing.
It gives us visibility from image creation to runtime, automatic ticketing for critical issues, and a shared view of container health — all without paying for heavy enterprise tooling.
Most importantly, it’s helped us build a stronger security culture in our R&D environment. Developers are now part of the security loop, not outside of it — and that shift has made all the difference.
