Security-First by Design
Security is not an afterthought. It is a foundational design principle that shapes how we build, test, release, and operate software.
As a security-first company, technical and operational processes are intentionally aligned around reducing risk, preventing misconfiguration, and enabling verifiable trust. This applies to application code, build pipelines, container images, deployment configuration, and runtime behavior.
Security is embedded directly into architectural decisions, development workflows, CI/CD pipelines, release processes, and runtime defaults. Security properties are enforced by design rather than by convention or manual intervention.
Best Practices and CIS Alignment
Containerized workloads require more than functional correctness. They must be designed, built, and operated according to established security and operational best practices to reduce risk, improve resilience, and support regulatory and compliance requirements.
The platform follows the Center for Internet Security (CIS) Docker Benchmark as a recognized baseline for secure container image construction and runtime configuration.
Best Practice Areas and CIS Mapping
| Best Practice Area | Description | CIS Reference |
|---|---|---|
| Minimal Runtime Images | Runtime images contain only required binaries. Package managers, network utilities, debugging tools, and auxiliary tooling are removed to reduce attack surface. | CIS Docker Benchmark Section 4 |
| Secure Build Pipeline | Images are built in controlled CI pipelines with reproducible builds, automated scanning, and signed artifacts. Security attestations are generated for every release. | CIS 4.4, 4.5, 4.12 |
| Secrets Management | Secrets are not embedded in images or Dockerfiles. Sensitive values are injected at runtime using file-based secret mounts. | CIS 4.10, 5.x |
| Non-Root Execution | Application containers run as non-root users with explicit file permissions and restricted writable paths. | CIS 4.8, 5.4 |
| Read-Only Root Filesystem | Container root filesystems are mounted read-only. Writable locations are explicitly defined with tmpfs or dedicated volumes. | CIS 5.13 |
| Capability Restriction | Linux capabilities are dropped by default and containers cannot acquire additional privileges at runtime. | CIS 5.4, 5.26 |
| Secure Runtime Configuration | Containers are started without privileged mode, host namespace sharing, or sensitive host mounts. | CIS 5.5-5.21 |
| Resource Controls | Memory and CPU limits are defined to prevent resource exhaustion and noisy-neighbor behavior. | CIS 5.11, 5.12 |
| Network Exposure Control | Only required ports are exposed. Privileged ports and host networking are avoided unless explicitly justified. | CIS 5.8-5.10 |
| Supply Chain Integrity | Images are signed and accompanied by SBOMs and security attestations to verify provenance and integrity. | CIS 4.5, 4.12 |
| Continuous Verification | Image hardening and runtime configuration are continuously validated using automated policy and security checks. | CIS Continuous Compliance Principles |
Design Philosophy
Controls are applied consistently across image build, configuration, and runtime deployment as a layered defense model. The platform emphasizes explicit configuration over implicit defaults, prevention of misconfiguration by design, and verifiable controls over informal assurances.
CIS Container Image Hardening
The CIS Docker Benchmark provides practical, consensus-based guidance for securing containerized workloads. The platform follows relevant recommendations for image creation, build pipelines, and runtime configuration to establish a practical and auditable baseline.
Scope and Applicability
- Container image build hardening
- Secure handling of secrets
- Supply chain integrity controls
- Container runtime configuration
- Operational guardrails enforced at deployment time
Out of Scope
- Host operating system hardening
- Kubernetes cluster-level CIS benchmarks
- Network perimeter security controls
Image Hardening and Build Controls
| ID | Description | Implementation |
|---|---|---|
| 4.4 | Ensure images are scanned and rebuilt to include security patches | Images are rebuilt regularly and scanned in CI with automated vulnerability scanners. Each release includes verifiable security attestations. |
| 4.5 | Ensure Content Trust for Docker is enabled | Images are cryptographically signed and verified during release. |
| 4.8 | Ensure setuid and setgid permissions are removed | No unnecessary SUID/SGID binaries are present; findings are explicitly reviewed. |
| 4.9 | Ensure COPY is used instead of ADD in Dockerfiles | Dockerfiles use COPY for predictable and auditable inclusion behavior. |
| 4.10 | Ensure secrets are not stored in Dockerfiles | Secrets are never embedded in images or Dockerfiles; secrets are runtime-injected. |
| 4.11 | Ensure only verified packages are installed | Only required packages are installed. Package managers, network utilities, debugging tools, and non-essential binaries are removed from runtime images. |
| 4.12 | Ensure all signed artifacts are validated | Image signatures and SBOMs are validated through supply chain controls. |
Container Runtime Configuration
Runtime defaults are restrictive and aligned with CIS Section 5 recommendations. Containers are isolated, non-privileged, and configured with explicit resource and mount constraints.
| ID | Description | Implementation |
|---|---|---|
| 5.4 | Restrict Linux kernel capabilities | All capabilities are dropped by default; only explicitly required capabilities may be added. |
| 5.5 | Avoid privileged containers | Containers are never started in privileged mode. |
| 5.6 | Avoid sensitive host mounts | No sensitive host directories are mounted into containers. |
| 5.7 | Avoid sshd in containers | No SSH daemon or remote login service is included in runtime images. |
| 5.8 | Avoid privileged port mappings | Privileged ports are not bound unless explicitly required and justified. |
| 5.9 | Expose only required ports | Only required application ports are exposed. |
| 5.10 | Avoid host network namespace sharing | Host networking is not used. |
| 5.11 | Limit container memory usage | Memory limits are explicitly defined at deployment time. |
| 5.12 | Set CPU priority and limits | CPU limits and quotas are configured per service. |
| 5.13 | Use read-only root filesystem | Root filesystem is read-only; writable paths use explicit tmpfs mounts. |
| 5.16 | Avoid host PID namespace sharing | Containers run in isolated PID namespaces. |
| 5.17 | Avoid host IPC namespace sharing | Containers run in isolated IPC namespaces. |
| 5.18 | Avoid host device exposure | No host devices are passed through to containers. |
| 5.20 | Avoid shared mount propagation | Shared mount propagation is not used. |
| 5.21 | Avoid host UTS namespace sharing | Containers do not share host UTS namespace. |
| 5.22 | Keep seccomp profile enabled | The default Docker seccomp profile is enforced. |
| 5.26 | Prevent new privileges | No-new-privileges is enabled for all containers. |
| 5.32 | Avoid Docker socket mounts | The Docker socket is never mounted into containers. |
Non-Root Execution Model
- Application containers run as non-root users
- File permissions are explicitly set during build
- Writable paths are restricted to explicitly defined directories
- Root filesystem remains immutable at runtime
Secure Handling of Secrets
Secrets such as encryption keys, signing keys, and credentials are treated as security-sensitive assets and are used only for explicit, purpose-driven operations.
The platform is designed so that required secrets are available at runtime where needed, while access remains controlled and predictable. Secrets are excluded from general configuration handling and protected from accidental exposure through logging and diagnostics.
- Secrets are never embedded in images or Dockerfiles
- Secrets are injected through runtime file-based mounts
- Application configuration references secrets via explicit
*_FILEpaths - Cryptographic keys are not reused across unrelated purposes
- Components interact only with secrets relevant to their role
The model applies consistently to encryption and integrity keys, signing keys, and internal trust credentials, improving maintainability and auditability.
Compliance as Code
Security and compliance are codified, automated, and continuously validated throughout delivery pipelines. Controls are treated as technical constraints rather than manual checks.
Pipeline-Enforced Controls
- Declarative security controls enforced automatically during build and release
- Fail-fast behavior when policy violations are detected
- Reproducible builds and deterministic packaging behavior
- Continuous vulnerability, hardening, and policy validation
- Dependency and supply chain inspection before release
Verifiable Evidence and Release Gating
- Cryptographically signed container images
- Software Bills of Materials (SBOMs)
- Security and build attestations
- Provenance metadata linking artifacts to source and build context
- Policy-gated release promotion with traceable exceptions
Because controls are encoded into pipeline and deployment configuration, behavior is consistent across environments and teams, and configuration drift is minimized.