Full Report
BellSoft survey finds 48% prefer pre‑hardened images over managing vulnerabilities themselves Java developers still struggle to secure containers, with nearly half (48 percent) saying they'd rather delegate security to providers of hardened containers than worry about making their own container security decisions.…
Analysis Summary
# Best Practices: Securing Java Container Deployments
## Overview
These practices address the stated challenges faced by Java developers in securing containers, which often stem from relying on general-purpose, potentially "bloated" base images, human error in configuration, and resource constraints in vulnerability management. The focus is on leveraging optimized, hardened solutions and implementing robust security hygiene across the container lifecycle.
## Key Recommendations
### Immediate Actions
1. **Conduct Immediate Vulnerability Sweep:** Run comprehensive vulnerability scans (using tools like Trivy, Clair, or platform-native scanners) against all currently deployed Java container images to identify high-severity CVEs immediately.
2. **Audit Base Image Sources:** Identify and document the base images (OS distributions and JDKs) currently used across all services. Flag any reliance on non-hardened, general-purpose Linux distributions or JDKs.
3. **Enable Basic Registry Trust:** Ensure that all container deployments are configured to pull images only from designated, trusted, and scanned container registries (45% of respondents already do this, but mandate 100% compliance).
### Short-term Improvements (1-3 months)
1. **Migrate to Hardened Base Images:** Prioritize replacing general-purpose base images with vendor-provided, pre-hardened, or minimal images (e.g., Alpine variants, distroless, or vendor-specific hardened JDK images) to reduce the attack surface significantly.
2. **Mandate Software Bill of Materials (SBOM) Generation:** Implement automated processes to generate and store an SBOM for every container build. This should be a mandatory step in the CI/CD pipeline (following the 18% usage rate, aim for 80%+ coverage immediately).
3. **Implement Pre-Runtime Image Signing:** Integrate container image signing (using tools like Notary or Cosign) into the build process and configure deployment environments (Kubernetes admission controllers, Docker daemon settings) to only run images with valid signatures (increasing the current 16% usage).
### Long-term Strategy (3+ months)
1. **Develop Hardened Image Standardization (If Not Subscribing Fully):** If external purchasing of hardened images is not 100% feasible, establish internal security teams to create and maintain standardized, minimal, and regularly patched base images specifically optimized for Java applications.
2. **Establish Formal Patch Management Policy:** Define clear organizational processes for responding to new CVEs, specifically targeting two metrics: (a) time to vulnerability detection and (b) time to secure image deployment, aiming to reduce time gaps before patches become available (addressing the 32% gap issue).
3. **Implement Security Training Focused on Human Error Reduction:** Develop targeted training modules addressing the 62% of mistakes attributed to human error. Focus training on secure configuration management (IaC), avoiding insecure defaults, and understanding dependency risks.
## Implementation Guidance
### For Small Organizations
* **Prioritize "Buy Over Build":** Since resource constraints are common, strongly favor leveraging vendor-supplied, pre-hardened container images (like Liberica's hardened versions). This delegates maintenance (addressing the 48% preference) to the vendor.
* **Automate Scanning:** Utilize free or low-cost integrated scanning tools within your existing CI/CD pipeline (e.g., GitHub Actions integrations, simple local scanners) rather than investing in complex enterprise solutions initially.
### For Medium Organizations
* **Adopt Image Signing:** Formalize the image signing process across all development teams to ensure that only verified artifacts reach staging and production environments.
* **Integrate SBOMs into Procurement/Review:** Use generated SBOMs as a mandatory checklist item when reviewing new application deployments or third-party dependencies.
* **Focus on Patching Automation:** Invest configuration time in scripting automated base image updates within development pipelines rather than manual patching to combat patching difficulties (36% issue).
### For Large Enterprises
* **Establish a Centralized Image Hardening Standard:** Create a central Container Security team responsible for defining, vetting, and distributing the approved, minimal base images used organization-wide, ensuring consistency and reducing developer decision points.
* **Implement Hardware Isolation Where Applicable:** For high-security workloads, explore and deploy hardware isolation technologies (like confidential computing or robust kernel separation) as a defense-in-depth measure (addressing the 6% usage).
* **Invest in False Positive Management:** Deploy advanced scanning tools, tune rulesets specifically for the validated, hardened images used, and establish processes to triage and suppress false positives to avoid developer security fatigue (addressing the 29% false positive complaint).
## Configuration Examples
*Specific configurations were not provided in the text, but general guidance based on the findings is:*
**Configuration Goal: Enforce Signed Images in Kubernetes**
1. **Tooling:** Utilize an admission controller like Kyverno or OPA Gatekeeper.
2. **Policy Snippet Example (Conceptual):** Configure a policy that checks the metadata of an incoming Pod specification:
yaml
# Policy to reject images unless they have a specific matching signature policy
match:
resources:
kinds: ["Pod"]
validate:
message: "Image must be signed by the trusted organization key ID."
pattern:
spec:
containers:
- name: "*"
image: "docker.io/mycorp/*@sha256:..." # Requires configuration to check signature metadata against policy store
## Compliance Alignment
* **NIST SP 800-204A:** Focusing on Container Security and Operationalizing Vulnerability Guidance. The move to minimal, hardened images directly supports supply chain integrity objectives within this framework.
* **ISO/IEC 27001 (A.14: System Acquisition, Development and Maintenance):** Mandating SBOMs and using trusted/verified images directly addresses controls for securing system acquisition and integration.
* **CIS Benchmarks for Docker/Kubernetes:** Utilizing minimal base images and enforcing image signing aligns with CIS recommendations for hardening the container runtime environment and supply chain integrity.
## Common Pitfalls to Avoid
* **Treating Security as a Post-Build Check:** Relying solely on scanning existing images without integrating security checks (SBOM, signing) earlier in the CI/CD pipeline leads to friction and delays.
* **Ignoring Human Error Focus:** Failing to provide clear, simple, standardized base images or ignoring training will likely perpetuate the 62% rate of human-caused security mistakes.
* **Sticking to "General Purpose" Defaults:** Continuing to use large, general-purpose Linux distributions and standard JDKs because they are familiar increases the attack surface unnecessarily, requiring excessive ongoing maintenance effort.
## Resources
* **Container Supply Chain Security Best Practices:** (Search for best practices from the Container Security Initiative or similar groups for deep dives on signing and SBOM standards).
* **Minimal Base Image Documentation:** Review documentation for "distroless" images or minimal Linux distributions for use as official hardened bases.
* **BellSoft State of Container Security Report (2025):** Review the full findings for deeper context on developer sentiment (external link provided in context).