Container Security | The Complete Checklist Guide for Defense-in-Depth

We’re a hub for tech professionals looking to advance & optimize their IT Infrastructure by finding the perfect product, tool, or role. Learn more about us. If you don’t see a product you are looking for on our website you can send us feedback 🙂

CarlosRecruits Icon

In this article, we will provide a comprehensive list of checks to make sure your container security is optimal. We will be diving into a series of policy checks that can be used for the overall security architecture of your containerized application.

Must utilize minimal supply chain by pulling binaries directly from the maintainers.

The policy check, “Must utilize minimal supply chain by pulling binaries directly from the maintainers,” relates to the security and integrity of the software supply chain in the context of containerized applications. Here’s a breakdown of what this policy is specifically asking for:

Understanding the Policy

  1. Minimal Supply Chain:
    • The term “minimal supply chain” implies reducing the number of steps or intermediaries involved in obtaining software components (like binaries) for your containers. A shorter supply chain typically means fewer points of potential compromise, leading to a more secure environment.
  2. Pulling Binaries Directly from the Maintainers:
    • This part of the policy emphasizes obtaining binaries directly from the original source, which is typically the software maintainers or official repositories. This approach ensures that the binaries are authentic and have not been tampered with.

Implications and Implementation

  • Direct Sources: Ensure that the software, libraries, or binaries included in your container images are downloaded directly from the official source (like official Docker images from Docker Hub, or binaries from the official project repositories).
  • Avoid Third-Party Sources: Avoid using third-party repositories or sources that are not directly maintained by the software developers. These sources might have altered or outdated versions of the software, which can pose a security risk.
  • Verification: Implement mechanisms to verify the integrity of the binaries. This can include checking cryptographic signatures or hash sums provided by the maintainers to ensure that the binaries have not been altered.
  • Regular Updates: Regularly update your binaries to ensure that you have the latest security patches and updates. This is crucial as older versions may contain vulnerabilities that have been fixed in newer releases.
  • Automated Scanning: Employ automated tools to scan for vulnerabilities in your containers, focusing on the binaries and dependencies they include.
  • Documentation and Audit Trail: Keep a record of where each binary came from, its version, and the verification checks performed. This documentation can be vital for audits and troubleshooting security incidents.

By adhering to this policy, you significantly reduce the risk of introducing vulnerabilities through compromised or malicious software components in your containerized applications. It’s a fundamental practice for maintaining a secure and trustworthy container environment.

Must verify the integrity of the binaries on every external access.

The policy item “Must verify the integrity of the binaries on every external access” emphasizes a crucial aspect of securing containerized applications, particularly in the context of the software supply chain. Let’s break down what this means and how it can be implemented:

Understanding the Policy

  1. Integrity of the Binaries:
    • This refers to ensuring that the binaries (executable files, libraries, etc.) used in your application are exactly as they were when they were created by the maintainers, without any unauthorized modifications. Modifications could indicate tampering, which could lead to security breaches.
  2. Verification on Every External Access:
    • The policy specifies that this integrity check should occur every time these binaries are accessed externally. This means that whenever your build process or your running application retrieves binaries from external sources, their integrity should be verified.

How to Implement This Policy

  1. Checksum Verification:
    • The most common method for verifying the integrity of binaries is to use checksums (like SHA-256 hashes). When you download a binary, you should also obtain its checksum, ideally from a separate, trusted source. You then compute the checksum of the downloaded file and compare it with the expected checksum. If they match, the integrity is verified.
  2. Cryptographic Signature Verification:
    • Another method is verifying cryptographic signatures. Some maintainers sign their binaries with a digital signature. You can use the maintainer’s public key to verify that the signature of the binary is valid, confirming that the binary hasn’t been tampered with and indeed comes from the stated source.
  3. Automated Tools for Continuous Verification:
    • Implement automated tools that continuously verify the integrity of binaries as part of your CI/CD pipeline. This ensures that every time your application is built, the binaries used are verified for integrity.
  4. Regular Updates and Scanning:
    • Continuously update your dependencies and binaries to their latest versions to ensure security. Also, use tools to regularly scan for vulnerabilities in your binaries and dependencies.
  5. Restrict External Sources:
    • Limit the sources from which binaries can be downloaded. Use trusted and well-known repositories. Avoid downloading binaries from unverified or suspicious sources.
  6. Logging and Auditing:
    • Keep logs of the integrity checks and any discrepancies found. Regular audits of these logs can help identify potential security issues.
  7. Container Scanning Tools:
    • Utilize container scanning tools that can check for vulnerabilities and also verify the integrity of the binaries within your containers.

By implementing these practices, you can significantly reduce the risk of using compromised binaries in your containerized applications, enhancing the overall security of your system.

Must be as current as possible to limit the impact of emerging vulnerabilities.

The policy item “Must be as current as possible to limit the impact of emerging vulnerabilities” highlights the importance of keeping your software, especially in containerized environments, up-to-date. This approach is aimed at mitigating risks associated with newly discovered security vulnerabilities. Here’s a detailed look at what this policy entails and how to implement it:

Understanding the Policy

  1. Staying Current:
    • This policy emphasizes the need to keep all software components within your container environment as up-to-date as possible. This includes the base container images, application dependencies, and any software tools or packages used.
  2. Limiting Impact of Emerging Vulnerabilities:
    • New vulnerabilities are discovered frequently in software components. By keeping your software current, you reduce the window of opportunity for attackers to exploit these vulnerabilities, as updates often include patches for recently discovered security flaws.

Implementation Strategies

  1. Regularly Update Base Images:
    • Regularly update the base images used in your Dockerfiles. For instance, if you’re using an image like node:current-alpine, ensure you rebuild your images frequently to get the latest version of Node.js and Alpine.
  2. Update Application Dependencies:
    • Regularly update the dependencies of your application. This can be done using package managers like NPM or Yarn for Node.js applications. Use commands like npm update to keep dependencies up-to-date.
  3. Automate the Update Process:
    • Implement automated tools or scripts that periodically check for updates of your base images and dependencies. Integrate these checks into your CI/CD pipeline.
  4. Vulnerability Scanning:
    • Use automated vulnerability scanning tools that can detect outdated software components and known vulnerabilities in your container images and application dependencies.
  5. Security Patches:
    • Prioritize applying security patches as soon as they are released. This is particularly important for critical vulnerabilities that are actively being exploited.
  6. Monitoring and Alerts:
    • Set up monitoring systems and subscribe to security bulletins or feeds for the software components you use. This will help you stay informed about new vulnerabilities and updates.
  7. Review Dependency Management Practices:
    • Regularly review your dependency management practices to ensure they align with best practices for security. This includes scrutinizing transitive dependencies (dependencies of your dependencies).
  8. Immutable Tags in Base Images:
    • Prefer using immutable tags over mutable tags like latest in your Dockerfiles. This ensures more controlled and predictable updates.
  9. Regular Audits:
    • Conduct regular audits of your software stack to ensure compliance with this policy.

By following these practices, you ensure that your containerized applications are less susceptible to emerging vulnerabilities, maintaining a strong security posture.

Must be as minimal as possible to reduce risk exposure

The policy “Must be as minimal as possible to reduce risk exposure” is focused on minimizing the attack surface of your containerized applications by keeping them as lean as possible. Let’s break down what this means and how it can be achieved:

Understanding the Policy

  1. Minimalist Approach:
    • The policy is advocating for a minimalist approach to your container configuration. This means including only the essential components necessary for your application to run. Every additional package, library, or service that is included in your container increases the potential attack surface.
  2. Reduced Risk Exposure:
    • By minimizing the contents of your containers, you reduce the number of potential vulnerabilities. Fewer components mean fewer opportunities for security flaws and therefore a lower risk of exploitation.

Implementing a Minimalist Approach

  1. Use Minimal Base Images:
    • Start with a minimal base image, like Alpine Linux, which is designed to be lightweight and secure. These base images contain only the bare essentials needed to run an application.
  2. Avoid Unnecessary Packages:
    • Only install the packages and dependencies that are absolutely necessary for your application. Avoid installing unnecessary tools or libraries.
  3. Multi-Stage Builds:
    • Use multi-stage builds in Docker. Build your application in a first stage with all necessary build tools and dependencies, and then copy only the necessary artifacts (like executables and libraries) to a final, minimal image.
  4. Regularly Scan and Audit Containers:
    • Use container scanning tools to identify and remove unused or unnecessary components. Regularly audit your containers to ensure they remain minimal.
  5. Review Dockerfiles:
    • Regularly review Dockerfiles for any unnecessary commands, layers, or files being added to the image.
  6. Use Specific Versions of Dependencies:
    • Specify exact versions of dependencies rather than using version ranges. This practice not only aids in creating a minimal setup but also contributes to reproducibility and consistency.
  7. Limit Runtime Privileges:
    • Run applications with the least privileges necessary. Avoid running applications as root unless absolutely necessary.
  8. Optimize Layer Caching:
    • Optimize Docker layer caching by ordering Dockerfile commands appropriately. This can help in reducing build times and the size of the final image.
  9. Regular Reviews and Updates:
    • Regularly review and update your container setups to remove any components that are no longer necessary.

By adhering to this minimalist approach, you effectively reduce the risk of vulnerabilities and potential attacks, making your containerized applications more secure.

Must be hosted on authorized container development platforms.

The policy “Must be hosted on authorized container development platforms” is about ensuring that the environments where you develop, build, and possibly store your containerized applications are secure, trusted, and officially sanctioned by your organization. Let’s explore what this entails:

Understanding the Policy

  1. Authorized Platforms:
    • This policy requires that all container development activities (like coding, building, testing) occur on platforms that are officially approved by your organization. This includes development environments, build systems, and repository hosting services.
  2. Security and Compliance:
    • Authorized platforms are typically those that meet your organization’s security standards and compliance requirements. They are vetted to ensure they uphold the necessary security protocols, data protection measures, and possibly other corporate policies.

Implementing the Policy

  1. Selecting Development Platforms:
    • Choose development platforms that are known for their security and reliability. This might include popular and well-supported platforms like Docker, Kubernetes, OpenShift, or cloud-based services like AWS ECS/EKS, Azure Container Instances/AKS, Google Kubernetes Engine, etc.
  2. Platform Vetting and Approval:
    • Before adopting a platform, it should go through a thorough vetting process. This process evaluates the platform’s security features, compliance with industry standards, data handling practices, and more.
  3. Access Control and Management:
    • Implement robust access control mechanisms on these platforms. Ensure that only authorized personnel have access to development tools and environments.
  4. Secure Configuration:
    • Ensure that the platforms are configured securely according to best practices. This includes network configurations, resource limitations, and the secure setup of development tools and services.
  5. Regular Security Audits:
    • Conduct regular audits of the platforms to ensure they remain secure and compliant with organizational policies.
  6. Integration with CI/CD Pipelines:
    • If these platforms are integrated into CI/CD pipelines, ensure that the entire pipeline maintains a high security standard, including the safe handling of secrets and credentials.
  7. Monitoring and Logging:
    • Set up monitoring and logging to track activities and detect potential security incidents in real-time.
  8. Training and Guidelines for Developers:
    • Provide training and guidelines to developers on how to use these platforms securely and in compliance with organizational policies.
  9. Vendor Support and Community:
    • Consider the level of support provided by the platform vendors and the activity of the community around these platforms, as this can impact the speed of addressing security issues and the availability of resources for troubleshooting.

By following this policy, you ensure that your container development process is conducted in a secure, controlled environment, which is critical for maintaining the overall security and integrity of your containerized applications.

The runtime user must be non-root or provide a detailed description of privileged execution is necessary.

The policy “The runtime user must be non-root or provide a detailed description of why privileged execution is necessary” emphasizes key security principles in the context of containerized applications. Let’s break it down:

Understanding the Policy

  1. Principle of Least Privilege:
    • This principle dictates that a process, user, or program should have only the minimum privileges necessary to perform its function. In the context of containers, this means running services and applications with the least amount of access rights they need to function properly.
  2. Separation of Privilege:
    • This concept involves dividing privileges among multiple users or processes to limit the potential damage from a compromise. It’s about ensuring that processes or users have access rights that are not only minimal but also distinct and separated based on their roles or functions.
  3. Non-Root Runtime User:
    • Containers should be run as a non-root user whenever possible. Running containers as root (the default in many cases) can pose a significant security risk, as it gives the container extensive privileges on the host system.
  4. Justification for Privileged Execution:
    • If there is a need for a container to run with elevated privileges (as root), this policy requires a detailed justification. This explanation should cover why such privileges are necessary and what measures are taken to mitigate associated risks.

Implementing the Policy

  1. Specify Non-Root User in Dockerfile:
    • In your Dockerfile, use the USER instruction to specify a non-root user for running the application. For instance, USER 1000:1000 or create a user with RUN adduser -D myuser and then switch to it with USER myuser.
  2. Minimize Capabilities:
    • Limit the capabilities of the container by using Docker’s security features like --cap-drop to drop unnecessary kernel capabilities.
  3. Security Context in Kubernetes:
    • If using Kubernetes, define a security context for your pods to ensure they run with a non-root user and have only the necessary privileges.
  4. Scrutinize Privileged Containers:
    • If a container must run as root, carefully analyze and document the reasons. Ensure that the use of root privileges is absolutely necessary and document how the risks are mitigated (e.g., using read-only filesystems, dropping unnecessary capabilities, network restrictions).
  5. Audit and Review:
    • Regularly audit containers to ensure compliance with this policy. Review the use of privileged containers and explore alternatives or additional security measures where possible.
  6. Least Privilege in Access and Operations:
    • Apply the least privilege principle not only to runtime privileges but also to other aspects like network access, file permissions, and inter-service communication.

By adhering to this policy, you significantly enhance the security of your containerized applications by minimizing the potential impact of a security breach. Running containers with minimal privileges is a fundamental best practice in container security.

Exposed ports should be in the non-privileged range (1025-65536), where possible, to allow the deployment platform to also adhere to least privilege.

The policy “Exposed ports should be in the non-privileged range (1025-65536), where possible, to allow the deployment platform to also adhere to least privilege” relates to the practice of using non-privileged ports for network communication in containerized applications. Let’s explore what this means and how it can be implemented:

Understanding the Policy

  1. Non-Privileged Port Range (1025-65536):
    • In Unix and Linux systems, ports in the range 0-1024 are considered privileged or reserved ports. They typically require root privileges to bind to, and they are assigned to well-known services (like HTTP on port 80, HTTPS on port 443).
    • Ports in the range 1025-65536 are considered non-privileged or user ports. They can be used by non-root users and processes.
  2. Least Privilege Principle:
    • By using non-privileged ports, the application adheres to the principle of least privilege, enhancing security. It reduces the risk associated with running processes as root solely for binding to a privileged port.

Implementing the Policy

  1. Dockerfile and Application Configuration:
    • Configure your application to listen on a non-privileged port. This might involve changing the application’s configuration files or environment variables.
    • In your Dockerfile, use the EXPOSE instruction to indicate which non-privileged port your container will use.
  2. Port Mapping:
    • When running your container, you can map the non-privileged port inside the container to a different port on the host, if necessary. This is done using the -p flag: docker run -p 80:8080 myimage
    • In this example, the container’s port 8080 is mapped to port 80 on the host. This allows your application to be accessed via a standard port on the host while still adhering to the non-privileged port usage inside the container.
  3. Network Policies and Security Groups:
    • Adjust any network policies or security group settings to allow traffic on the chosen non-privileged ports.
  4. Documentation and Communication:
    • Document the use of non-privileged ports in your application deployment guides. Ensure that team members and stakeholders are aware of the port configuration.
  5. Regular Review and Auditing:
    • Regularly review and audit your container configurations to ensure that non-privileged ports are used where possible.

Adopting non-privileged ports for exposed services in your containerized applications is a key aspect of adhering to security best practices. It allows your applications to run without unnecessary root privileges while still being accessible as needed. This practice, combined with proper port mapping and network configuration, can significantly enhance the security posture of your container deployment environment.

Not include embedded credentials or other sensitive information.

The policy “Not include embedded credentials or other sensitive information” is crucial for maintaining the security of containerized applications. It addresses the risk associated with storing sensitive data, like passwords, API keys, or certificates, directly in the container image or source code. Here’s a breakdown of this policy and how to adhere to it:

Understanding the Policy

  1. Avoid Embedding Credentials:
    • This policy dictates that credentials, such as usernames and passwords, API tokens, SSH keys, and other sensitive authentication data, should not be hardcoded or embedded within the container image or the application’s source code.
  2. No Sensitive Information:
    • Alongside credentials, other sensitive information like private encryption keys, configuration files with sensitive details, and personal data should also not be included in the image or source code.

Implementing the Policy

  1. Environment Variables:
    • Use environment variables for passing sensitive information into the container at runtime. This can be done using Docker’s -e flag in the docker run command or in Docker Compose files.
    • Example: docker run -e "API_KEY=your_api_key" myimage
  2. Secret Management Systems:
    • Utilize secret management tools to handle sensitive data. Tools like HashiCorp Vault, AWS Secrets Manager, or Docker Secrets (for Docker Swarm) allow you to securely store and manage access to secrets.
  3. Orchestration Tools:
    • If you’re using container orchestration tools like Kubernetes, take advantage of their built-in secrets management features. Kubernetes Secrets can be used to store and pass sensitive information to your containers.
  4. Volume Mounts for Sensitive Files:
    • Use volumes to mount sensitive files into the container at runtime, instead of including them in the image. For instance, SSL/TLS certificates can be mounted as volumes.
  5. Avoid Storing Secrets in Source Code:
    • Ensure that secrets are not stored in your application’s source code or in public repositories. Use .gitignore or similar mechanisms to exclude sensitive files from version control.
  6. Regular Audits and Scans:
    • Conduct regular code audits and scans to check for accidentally embedded secrets. Tools like GitGuardian or TruffleHog can help in scanning repositories for secrets.
  7. Use Config Maps for Non-Sensitive Configuration:
    • For non-sensitive configuration data, use mechanisms like Docker Configs (in Swarm) or ConfigMaps (in Kubernetes) to manage configurations separately from the container image.
  8. Implement Access Controls:
    • Ensure strict access controls for any system where secrets are stored or managed.
  9. Education and Policy Enforcement:
    • Educate team members about the risks of embedded credentials and enforce policies to prevent such practices.

By adhering to this policy, you significantly reduce the risk of credential leaks and security breaches. Proper management of sensitive information and credentials is a fundamental aspect of container security and should be a priority in any containerized application development and deployment process.

Utilize an additive approach to dependencies and code, which shall only include necessary dependencies and segments.

The policy “Utilize an additive approach to dependencies and code, which shall only include necessary dependencies and segments” focuses on a strategic and minimalistic approach to building your application and its container image. This approach is about carefully selecting and adding only what is necessary, rather than starting with a broad set of components and removing the unnecessary ones. Let’s break down this policy:

Understanding the Policy

  1. Additive Approach to Dependencies:
    • This means starting with the bare minimum and consciously adding each dependency your application specifically requires. It’s about being deliberate in choosing what libraries, frameworks, and tools are included in your application.
  2. Only Necessary Code and Dependencies:
    • The policy emphasizes including only the code and dependencies that are absolutely essential for your application to function. This reduces the overall size of your application, minimizes the attack surface, and makes maintenance easier.

Implementing the Policy

  1. Minimal Base Images:
    • Choose a minimal base image for your Dockerfile. For instance, images based on Alpine Linux are a popular choice due to their small footprint.
  2. Evaluate and Add Dependencies:
    • Carefully evaluate each library or framework you plan to add to your project. Ensure that it’s necessary and that you’re using the most up-to-date and secure version.
  3. Avoid Unnecessary Packages:
    • When installing packages in your Dockerfile or through package managers (like npm, pip), avoid installing unnecessary packages or tools. Use flags that prevent installing optional or recommended packages that aren’t essential.
  4. Optimize Layers in Dockerfile:
    • When writing your Dockerfile, structure it to create the fewest layers necessary and to reuse layers as efficiently as possible. This helps in reducing the image size.
  5. Code Audits and Reviews:
    • Regularly review and audit your application’s codebase to identify and remove unused code, outdated libraries, or unnecessary features.
  6. Container Scanning:
    • Use container scanning tools to analyze your images for vulnerabilities, especially those introduced by third-party dependencies. This helps ensure that only necessary and secure dependencies are included.
  7. Dependency Management Tools:
    • Utilize dependency management tools to keep track of what is included in your application. Tools like Dependabot can also help in keeping dependencies up to date and secure.
  8. Documentation:
    • Document the purpose and need for each dependency in your project. This not only aids in transparency but also helps in future audits and maintenance.

Utilize multi-stage builds to minimize containers when build dependencies are greater in number or size than runtime dependencies.

The policy “Utilize multi-stage builds to minimize containers when build dependencies are greater in number or size than runtime dependencies” is about optimizing Docker container images, especially when there’s a significant difference between the number or size of dependencies needed for building the application and those required for running it. Let’s break down what this means and how to implement it:

Understanding the Policy

  1. Multi-Stage Builds:
    • Multi-stage builds in Docker are a way to create lean and efficient container images by separating the build stage from the runtime stage.
    • In a multi-stage build, you use multiple FROM statements in your Dockerfile. Each FROM statement begins a new stage and can use a different base image.
  2. Minimize Container Size:
    • This policy aims to minimize the size of the final container image. Build-time dependencies often include compilers, build tools, and various libraries that are not needed once the application is compiled or built.
  3. Differentiate Between Build and Runtime Dependencies:
    • Recognize that the dependencies required to build your application are often more numerous or larger than those required to run it. By using multi-stage builds, you can include these heavy dependencies only in the build stage, not in the final runtime image.

Implementing the Policy

  1. Define Build Stage:
    • Start with a base image that includes your build tools and dependencies. Perform all necessary steps to build your application in this stage.
    • Example for a Node.js app:
FROM node:16 as builder
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build
  • Define Runtime Stage:
  • After the build stage, start a new stage with a leaner base image, typically one that contains only the runtime environment required to run your application.
  • Then copy only the necessary artifacts from the build stage to the runtime stage.
  • Continuing the Node.js example:
FROM node:16-alpine
COPY --from=builder /app/dist ./dist
CMD ["node", "dist/main.js"]
  1. Optimize for Size and Security:
    • Choose base images and build steps that are optimized for size and security. For example, use Alpine-based images where possible, as they are smaller and more secure.
  2. Regularly Update and Review:
    • Regularly update and review your Dockerfiles to ensure that you’re using the most efficient multi-stage build process. This includes updating base images and dependencies to their latest, most secure versions.
  3. Testing and Validation:
    • Test the built containers thoroughly to ensure that they function correctly with only runtime dependencies.

Utilize container optimization tools to further minimize containers and/or use distroless as the final layer.

Utilize container optimization tools to further minimize containers and/or use distroless as the final layer.

The policy “Utilize container optimization tools to further minimize containers and/or use distroless as the final layer” addresses two key strategies for enhancing container security and efficiency. Let’s break down each part of this policy:

1. Utilizing Container Optimization Tools


  • Container optimization tools help reduce the size of your Docker images and remove unnecessary components, thus minimizing the potential attack surface.

How to Implement:

  1. Use Image Optimization Tools:
    • Tools like DockerSlim, BuildKit, or can analyze and optimize your Docker images. They identify and remove unnecessary files, layers, and settings.
  2. Automate Optimization in CI/CD:
    • Integrate these tools into your Continuous Integration and Continuous Deployment (CI/CD) pipeline. This ensures that all images are automatically optimized as part of your build process.
  3. Regularly Scan and Optimize:
    • Regularly scan your images for size optimizations and vulnerabilities, and refine them based on the recommendations of these tools.

2. Using Distroless as the Final Layer


  • Distroless images are minimal images provided by Google that contain only your application and its runtime dependencies. They do not include package managers, shells, or any other binaries you would find in a standard Linux distribution. This minimizes the attack surface.

How to Implement:

  1. Switch to Distroless Images:
    • In your Dockerfile, use a distroless image as the base for the final stage of your build. Google Container Tools provides distroless images for various languages and applications.
  2. Example for a Node.js App:
# Build stage
FROM node:16 as builder
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build

# Distroless stage
COPY --from=builder /app/dist /app
CMD ["main.js"]
  1. Test for Compatibility:
    • Ensure your application runs correctly on distroless images, as they lack a shell and other utilities. This might require changes in how you manage logs, debug issues, or execute health checks.
  2. Combine with Multi-Stage Builds:
    • Distroless images work well with multi-stage builds, using a fuller image for the build stage and then copying only the necessary artifacts to the distroless image.

Use minimized containers in production unless no other options are available for the use case.

The policy “Use minimized containers in production unless no other options are available for the use case” emphasizes the importance of deploying the leanest, most efficient container images in a production environment. This approach is geared towards enhancing security and performance. Let’s explore what this entails and how to implement it:

Understanding the Policy

  1. Minimized Containers:
    • This refers to containers that have been stripped of all non-essential components. These containers contain only the runtime dependencies necessary for the application, minimizing their size and reducing potential security vulnerabilities.
  2. Production Environment Focus:
    • The policy specifically targets production environments, where security and resource efficiency are paramount.
  3. Exception Clause:
    • It acknowledges that in some specific use cases, it might not be possible to use minimized containers. In such scenarios, the use of more comprehensive containers is allowed, but these cases should be the exception rather than the rule.

Implementing the Policy

  1. Utilize Multi-Stage Builds:
    • Implement multi-stage builds in your Dockerfiles to separate the build environment from the runtime environment. This practice ensures that only the necessary artifacts from the build process are included in the final production image.
  2. Choose Minimal Base Images:
    • Opt for minimal base images like Alpine Linux, which are designed to be lightweight and secure.
  3. Optimize Dependencies:
    • Include only the libraries and dependencies that are absolutely necessary for the runtime. Regularly review and update these dependencies to maintain a minimal footprint.
  4. Use Distroless Images:
    • Consider using distroless images for your runtime environment, as they are specifically designed to include only your application and its runtime dependencies.
  5. Leverage Container Optimization Tools:
    • Use container optimization tools to analyze and further reduce the size of your container images.
  6. Regular Audits and Reviews:
    • Conduct regular reviews and audits of your container images to ensure they remain minimal and do not accrue unnecessary additions over time.
  7. Document Exceptions:
    • For cases where a minimized container is not feasible, document the reasons and the specific requirements that necessitate the use of a more comprehensive container.
  8. Security Scanning:
    • Regularly scan your container images for vulnerabilities, especially when not using minimized containers, to ensure any additional components do not introduce security risks.

Run a single command unless a security reason requires a second security-focused process to be running.

The policy “Run a single command unless a security reason requires a second security-focused process to be running” is about adhering to container best practices, particularly the principle of running a single primary process in a container. This approach simplifies management, enhances security, and improves the reliability of containers. Let’s break down this policy and its implementation:

Understanding the Policy

  1. Single Process Principle:
    • Containers are designed to run a single main process. When a container is used to run multiple processes, it often complicates container management, monitoring, and troubleshooting.
  2. Exceptions for Security Processes:
    • The policy allows for an exception when a secondary process is required for security reasons. This could include, for instance, a sidecar container for logging, monitoring, or security scanning.

Implementing the Policy

  1. Dockerfile Command Structure:
    • In your Dockerfile, use the CMD instruction to specify the primary command that runs when the container starts. This should be the main process of your application.
    • Example:
CMD ["node", "app.js"]
  1. Avoid Running Multiple Services:
    • Avoid configurations where the container runs multiple services, like a web server and a database together. Instead, use separate containers for each service, managed together using a tool like Docker Compose or Kubernetes.
  2. Use Sidecar Containers for Auxiliary Processes:
    • If a secondary, security-focused process is necessary, consider using a sidecar container pattern. In this pattern, the secondary process runs in a separate but related container, often sharing some resources with the primary container.
  3. Security-Focused Processes:
    • Examples of security-focused processes that might run alongside the main application include:
      • Log collectors or forwarders.
      • Monitoring agents.
      • Security scanners or agents.
  4. Use Init System for PID 1 if Necessary:
    • If you need to handle multiple processes for a valid reason, use an init system like tini as PID 1. tini can handle proper signal forwarding and orphaned process reaping.
  5. Document Exceptions:
    • If your container needs to run a secondary security-focused process, document this clearly, explaining why it’s necessary and how it’s managed.

Limit containers to a single listening service at most except where a health or security service needs to be included in the container rather than pod.

The policy “Limit containers to a single listening service at most except where a health or security service needs to be included in the container rather than pod” is designed to promote best practices in container architecture for both security and simplicity. Let’s explore what this means and how to implement it:

Understanding the Policy

  1. Single Listening Service:
    • The policy advocates that each container should ideally run a single primary service that listens on a network port. This aligns with the microservices philosophy where each service is responsible for one aspect of the overall application functionality.
    • For example, one container might run a web server, another a database, and a third a caching service.
  2. Exception for Health or Security Services:
    • The policy allows an exception for health check or security-related services. These are additional processes or services within the container that are necessary for monitoring the health of the primary service or enhancing its security.
    • This might include, for example, a process that reports metrics or a sidecar container that manages security policies.

Implementing the Policy

  1. Dockerfile and Service Configuration:
    • Configure your Dockerfile so that the main process (started by CMD or ENTRYPOINT) is the primary service of your container.
    • Avoid configurations where multiple services are running in the same container, as this can lead to complex dependencies and makes the container harder to manage and scale.
  2. Health Checks:
    • Implement health checks within your container. In Docker, you can use the HEALTHCHECK instruction in the Dockerfile.
    • For example:
HEALTHCHECK --interval=30s --timeout=30s --start-period=5s --retries=3 CMD curl -f http://localhost/ || exit 1

In Kubernetes, define liveness and readiness probes in your deployment configuration.

  1. Security Services:
    • If a security process must run within the same container, ensure it is lightweight and does not interfere with the primary service. Document why it is necessary to include it within the container rather than handling it at the pod or orchestration layer.
  2. Use Sidecar Patterns for Additional Services:
    • Consider using the sidecar pattern for additional functionalities like logging, monitoring, or security. In this pattern, each sidecar container runs alongside the main container, usually within the same pod in Kubernetes, to extend or enhance the functionality of the original container.
  3. Document Exceptions:
    • Where exceptions are made for health or security services, document these clearly, explaining why they are necessary and how they are managed.
  4. Monitoring and Logging:
    • Set up monitoring and logging mechanisms that are compatible with this architecture. Ensure that these services are lightweight and do not significantly impact the performance of the primary service.

Must provide a mechanism for secure and collaborative source code management, such as GitLab.

The policy “Must provide a mechanism for secure and collaborative source code management, such as GitLab” underscores the importance of using a robust and secure system for managing and collaborating on source code. This is a critical aspect of software development, especially in teams and organizations where code quality, security, and effective collaboration are paramount. Here’s what this entails and how to implement it:

Understanding the Policy

  1. Secure Source Code Management:
    • The policy requires a system that ensures the security of your source code. This includes protection against unauthorized access, secure handling of code changes, and safe storage of code repositories.
  2. Collaborative Features:
    • The system should facilitate collaboration among team members. This includes features like branch management, merge requests, code reviews, and possibly issue tracking and CI/CD integration.
  3. Example: GitLab:
    • GitLab is mentioned as an example of such a system. It provides a comprehensive suite of tools for source code management, along with additional features for project management and CI/CD, all within a secure and collaborative environment.

Implementing the Policy

  1. Choose a Source Code Management Tool:
    • Select a tool or platform that offers robust source code management capabilities. GitLab, GitHub, and Bitbucket are popular examples, each with its own set of features and security measures.
  2. Ensure Secure Access:
    • Set up secure access controls. This includes using strong authentication methods (like two-factor authentication), setting up fine-grained access permissions for different team members, and regularly auditing access rights.
  3. Encourage Collaborative Practices:
    • Foster a culture of collaboration through regular code reviews, pair programming sessions, and utilizing merge/pull request workflows to manage contributions to the codebase.
  4. Integrate CI/CD Tools:
    • Integrate Continuous Integration/Continuous Deployment (CI/CD) tools with your source code management system. This allows for automated testing and deployment of code, enhancing both the efficiency and quality of your software development process.
  5. Use Branching Strategies:
    • Implement effective branching strategies (like Git Flow or Trunk Based Development) to manage different stages of development and to streamline the process of integrating new features and bug fixes.
  6. Regular Backups:
    • Ensure that there are regular backups of the source code to prevent data loss in case of accidental deletions or system failures.
  7. Security Scanning and Audits:
    • Utilize tools for static code analysis, vulnerability scanning, and perform regular security audits on your codebase to identify and rectify potential security issues.
  8. Documentation and Training:
    • Provide adequate documentation and training for team members on how to use the chosen source code management tool effectively and securely.

Must provide executors to enable secure and unprivileged container builds, such as GitLab runners.

The policy “Must provide executors to enable secure and unprivileged container builds, such as GitLab runners” addresses the need for secure environments for building container images. This policy is crucial for maintaining the integrity and security of the container build process. Let’s explore what this involves and how to implement it:

Understanding the Policy

  1. Secure Executors for Container Builds:
    • Executors in this context are environments or services that perform the task of building container images. The policy calls for these executors to be secure, meaning they should be configured and managed in a way that minimizes security risks.
  2. Unprivileged Builds:
    • Building containers in an unprivileged mode means that the build process doesn’t require or grant elevated permissions that could pose a security risk. This is important to prevent potential exploits during the build process.
  3. Example: GitLab Runners:
    • GitLab Runners are cited as an example. They are agents that automate the process of building, testing, and deploying applications based on instructions defined in a .gitlab-ci.yml file. GitLab Runners can be configured to build containers in a secure and unprivileged manner.

Implementing the Policy

  1. Set Up CI/CD Executors:
    • Choose and set up a CI/CD system that supports secure and unprivileged execution of build jobs. GitLab Runners are a popular choice, but other CI/CD systems like Jenkins, GitHub Actions, or CircleCI can also be configured for secure container builds.
  2. Configure for Unprivileged Operation:
    • Configure your build executors to operate in unprivileged mode. This can involve setting them up to run under non-root user accounts and ensuring they don’t require elevated permissions to execute build tasks.
  3. Use Secure Build Environments:
    • Ensure that the environment where the build is taking place is secure. This includes using trusted base images, scanning for vulnerabilities, and isolating build processes from other network and system resources.
  4. Implement Build Access Controls:
    • Control access to the build process. Only authorized personnel should be able to trigger builds or modify the build configuration.
  5. Audit and Logging:
    • Enable logging and auditing for the build process to track any changes, access, and actions taken during the build process.
  6. Isolate Build Environments:
    • Consider using isolated or ephemeral environments for each build to prevent any cross-contamination between builds and to ensure a clean, predictable build environment.
  7. Regular Updates and Patching:
    • Keep the build executors and the environments they run in updated with the latest security patches and updates.
  8. Secure Handling of Secrets:
    • Securely manage secrets required during the build process, such as credentials for accessing private repositories. Use secret management tools and avoid hardcoding secrets into build scripts or configuration files.

Must provide version-controlled registries for containers and security artifacts.

The policy “Must provide version-controlled registries for containers and security artifacts” emphasizes the importance of having a system in place to store and manage versions of both container images and related security artifacts. This approach is essential for maintaining consistency, traceability, and security in software deployment processes. Let’s break down what this entails and how to implement it:

Understanding the Policy

  1. Version-Controlled Registries for Containers:
    • This part of the policy refers to the use of container registries that support versioning. Each time a container image is updated or changed, it should be tagged with a unique version number. This allows for precise control over which version of an image is being used in any environment.
  2. Registries for Security Artifacts:
    • Security artifacts can include things like SSL/TLS certificates, cryptographic keys, or security policies. The policy suggests that these should also be stored in a version-controlled manner, ensuring that changes are tracked and managed effectively.

Implementing the Policy

  1. Set Up Container Registries:
    • Use container registries that support version tagging. Options include Docker Hub, AWS Elastic Container Registry (ECR), Google Container Registry (GCR), and Azure Container Registry (ACR), among others.
    • When pushing new images to the registry, use tags to identify different versions.
  2. Version Control for Security Artifacts:
    • Utilize tools or systems that can store and manage versions of security artifacts. This could be part of a broader software configuration management system.
    • Ensure changes to these artifacts are tracked, audited, and reversible.
  3. Integrate with CI/CD Pipelines:
  4. Automate Version Tagging:
    • Implement automation for tagging new versions of container images in your CI/CD pipeline. This can involve semantic versioning or using build numbers or timestamps as part of the tag.
  5. Access Control and Security:
    • Implement robust access controls for your registries. Ensure that only authorized personnel can make changes or push new versions.
    • Secure your registries and the artifacts within them. For container registries, this includes scanning images for vulnerabilities.
  6. Documentation and Compliance:
    • Document your versioning strategy and ensure it complies with any relevant organizational policies or industry standards.
  7. Backup and Recovery Procedures:
    • Establish backup and recovery procedures for your registries to prevent data loss and ensure business continuity.

Must provide a mechanism for secure and collaborative project management, documentation, and static content host.

The policy “Must provide a mechanism for secure and collaborative project management, documentation, and static content host” emphasizes the need for tools or platforms that support team collaboration in a secure environment, particularly for managing projects, maintaining documentation, and hosting static content. This is essential for efficient teamwork, knowledge sharing, and ensuring the security of information and resources. Let’s break down how to implement this policy:

Implementing the Policy

  1. Project Management Tools:
    • Choose a project management tool that offers features like task tracking, issue tracking, milestones, and collaborative boards. Examples include Jira, Asana, Trello, and GitLab Issues.
    • Ensure the tool allows for setting access controls and permissions to maintain security.
  2. Documentation Platforms:
    • Use a documentation platform that supports collaborative editing and version control. Options include Confluence, ReadTheDocs, DokuWiki, or integrated wikis in platforms like GitLab or GitHub.
    • Documentation should be easily accessible to team members but secured against unauthorized access.
  3. Static Content Hosting:
    • For hosting static content (like HTML pages, images, JavaScript, CSS), consider services that offer hosting with security features. This could be part of a broader Content Management System (CMS) or specific platforms like Netlify, GitHub Pages, or GitLab Pages.
    • Ensure proper access controls and security measures (like HTTPS) are in place.
  4. Integration and Workflow Automation:
    • Integrate these tools as much as possible to streamline workflows. For instance, linking documentation or static content updates directly to project management tasks.
    • Automate common processes, like notifications for project updates or documentation changes.
  5. Secure Access and Authentication:
    • Implement strong authentication mechanisms, such as two-factor authentication (2FA), to secure access to these tools.
    • Regularly review and manage user access to ensure only authorized personnel have access to sensitive information.
  6. Compliance and Data Protection:
    • Choose tools that comply with relevant data protection regulations and standards (like GDPR, HIPAA, etc.), especially if handling sensitive or personal data.
    • Regularly back up data to prevent loss and ensure business continuity.
  7. Collaboration Features:
    • Leverage features that enhance collaboration, like comment threads, shared workspaces, real-time editing, and version history.
  8. Training and Guidelines:
    • Provide training for team members on how to effectively use these tools. Establish guidelines for project management, documentation standards, and content publishing.
  9. Audit and Review:
    • Regularly audit the use of these tools for security compliance and review their effectiveness in facilitating project management and collaboration.

Should provide self-service for as many components of the container application development platform as possible.

Must provide a mechanism that enables the assessment of supply chain security risks, which, at a minimum, enforces the scanning of all dependencies for malicious signatures.

The policy “Must provide a mechanism that enables the assessment of supply chain security risks, which, at a minimum, enforces the scanning of all dependencies for malicious signatures” underscores the importance of securing the software supply chain. In the context of containerized applications and DevOps, this involves implementing processes and tools to scrutinize and secure every part of the software supply chain – especially dependencies – to prevent security vulnerabilities and breaches. Let’s explore how to implement this policy:

Implementing the Policy

  1. Dependency Scanning Tools:
    • Utilize tools that can scan software dependencies for known vulnerabilities and malicious signatures. This includes container images and any third-party libraries or packages your application uses.
    • Examples of such tools are Snyk, SonarQube, WhiteSource, and Black Duck.
  2. Integrate Scanning into CI/CD Pipeline:
    • Integrate these scanning tools into your Continuous Integration/Continuous Deployment (CI/CD) pipelines. This ensures that every build automatically undergoes a thorough check for vulnerable dependencies.
    • For containerized environments, also include scanning of the Dockerfiles and container images.
  3. Regularly Update Dependencies:
    • Implement a process for regularly updating dependencies to their latest, secure versions. This helps to mitigate the risk of using outdated libraries with known vulnerabilities.
  4. Software Composition Analysis (SCA):
    • Use Software Composition Analysis tools to get a comprehensive view of the software and components used in your application. SCA tools can identify open-source components and their licenses, security vulnerabilities, and other risks.
  5. Container Image Scanning:
    • Use tools like Clair, Trivy, or Anchore to scan container images for vulnerabilities. These tools can be integrated into your container registry or CI/CD pipeline.
  6. Source Code Analysis:
    • Implement Static Application Security Testing (SAST) to analyze source code for potential security issues.
  7. Track and Audit:
    • Maintain an inventory of all dependencies and regularly audit them. Keep track of where dependencies are sourced from and any known security issues.
  8. Respond to Vulnerabilities:
    • Establish a process for responding to detected vulnerabilities, including patching or updating affected components and, if necessary, adjusting your software architecture.
  9. Training and Awareness:
    • Educate your development team about supply chain security risks and best practices for secure coding and dependency management.
  10. Open-Source Security:
  • If using open-source components, monitor relevant databases and community forums for any security advisories related to those components.

Must include a mechanism that enables the tracking and verification of cryptographic signature chains for containers and authorization statuses.

The policy “Must include a mechanism that enables the tracking and verification of cryptographic signature chains for containers and authorization statuses” focuses on ensuring the integrity and authenticity of container images, as well as managing and verifying the authorization statuses associated with them. This is a crucial aspect of container security, as it helps to prevent unauthorized or tampered images from being deployed in your environment. Here’s how to implement this policy:

Implementing the Policy

  1. Cryptographic Signing of Container Images:
    • Implement a system where all container images are cryptographically signed. This involves attaching a digital signature to the image, which is created using a private key. The signature can later be verified using a public key, ensuring the image has not been tampered with since it was signed.
    • Tools like Docker Content Trust (using Notary), Sigstore, or Red Hat’s Container Image Signing can be used for this purpose.
  2. Verification of Signatures:
    • Configure your container runtime environment to verify the signatures of container images before running them. This ensures that only images that have been signed by trusted entities are used.
    • For Docker, you can enable Docker Content Trust, which ensures that all operations with a Docker registry enforce the signing and verification of images.
  3. Managing Authorization Statuses:
    • Maintain a system for managing the authorization status of entities (developers, CI/CD pipelines, etc.) that are allowed to sign and push container images.
    • Use role-based access control (RBAC) to define who can sign images and who can push them to your registries.
  4. Integrate with CI/CD Pipelines:
    • Integrate the signing process into your CI/CD pipelines. When a new image is built and ready for deployment, it should be automatically signed using a secure key.
  5. Secure Key Management:
    • Securely manage the keys used for signing images. This might involve using hardware security modules (HSMs) or key management services provided by cloud providers.
    • Ensure that private keys are kept confidential and protected.
  6. Audit Trails and Logging:
    • Maintain audit trails and logs for all signing activities. Record who signed which image and when, as well as any changes to authorization statuses.
  7. Regular Review and Revocation Mechanisms:
    • Regularly review your cryptographic signatures and authorization policies. Have mechanisms in place to revoke keys or alter authorization statuses if needed.
  8. Training and Policy Enforcement:
    • Train relevant personnel on the importance of image signing and the procedures for verifying signatures. Ensure strict adherence to the policy.

Should provide a messaging and alerting service for real-time collaboration and bot integration.

The policy “Should provide a messaging and alerting service for real-time collaboration and bot integration” focuses on the importance of effective communication within a team, particularly in real-time scenarios, and the integration of automated processes (bots) for efficiency and enhanced collaboration. Implementing this policy involves setting up tools and systems that facilitate instant messaging, alerts, and integration with automated bots. Here’s how to approach it:

Implementing the Policy

  1. Choosing a Messaging Platform:
    • Select a messaging platform that supports real-time communication and is widely used by your team. Popular options include Slack, Microsoft Teams, Discord, and Mattermost.
    • Ensure the platform supports both direct messaging and group channels for team discussions.
  2. Alerting Services:
    • Integrate alerting services that notify team members of important events, such as system outages, completed tasks, or urgent messages. This could be part of your existing messaging platform or a dedicated tool like PagerDuty or Opsgenie.
  3. Bot Integration:
    • Leverage bots within your messaging platform for automation of routine tasks. Bots can be used for a variety of purposes, such as:
      • Notifying teams of new commits, merge requests, or CI/CD pipeline status updates.
      • Automating responses to common queries.
      • Integrating with issue tracking systems to update task statuses.
    • Many messaging platforms have built-in support for bots or allow integration with external bot services.
  4. Custom Notifications and Webhooks:
    • Utilize webhooks to send custom notifications from your tools and services to your messaging platform. For example, configuring your project management tool to send updates on task progress.
  5. Security and Access Control:
    • Implement appropriate security measures for your messaging and alerting services. This includes managing user access, securing sensitive data shared over messages, and ensuring compliance with data protection regulations.
  6. Documentation and Guidelines:
    • Document the process and guidelines for using the messaging and alerting services. Include instructions on how to interact with bots and how to configure personal notification settings.
  7. Training and Onboarding:
    • Provide training or resources to help team members effectively use these tools. This is particularly important for less tech-savvy team members or those new to the organization.
  8. Feedback and Continuous Improvement:
    • Regularly gather feedback from the team on the effectiveness of the communication tools and make improvements as necessary.

Credential detection on the project.

The policy “Credential detection on the project” focuses on the implementation of measures to detect and manage credentials (like passwords, API keys, or tokens) within a project’s codebase, configuration files, or other relevant areas. This is crucial for preventing sensitive credentials from being exposed, which can lead to security vulnerabilities. Here’s how to implement this policy:

Implementing the Policy

  1. Automated Scanning Tools:
    • Use automated tools that scan the codebase and other relevant files for accidentally committed credentials. Tools like GitGuardian, TruffleHog, or AWS CodeCommit can detect credentials embedded in code repositories.
  2. Integrate with CI/CD Pipeline:
    • Integrate credential scanning into your Continuous Integration (CI) process. Ensure that every code commit or build is automatically scanned for exposed credentials.
  3. Pre-Commit Hooks:
    • Implement pre-commit hooks in your version control system. These hooks can scan for credentials before code is committed and alert the developer if any are found.
  4. Regular Audits:
    • Conduct regular manual audits of the codebase and configuration files to check for credentials, especially in areas where automated tools might not reach.
  5. Secure Credential Storage:
    • Educate team members on using secure methods to store and access credentials, such as environment variables, secret management systems (like HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault), or configuration management tools.
  6. Review and Rotate Credentials:
    • In case credentials are found in the codebase, immediately rotate them to invalidate any exposed secrets and review how they were exposed to prevent future occurrences.
  7. Developer Training:
    • Train developers and other relevant team members on the importance of not hardcoding credentials and on the proper methods of managing secrets.
  8. Source Code Management (SCM) Policies:
    • Set up policies in your SCM system to prevent pushing code that contains credentials. Some platforms offer native scanning features or allow integration with third-party tools.
  9. Feedback and Reporting Mechanism:
    • Establish a mechanism for developers to report potential credential leaks and receive feedback on handling them.
  10. Documentation and Best Practices:
  • Document best practices for managing credentials securely and make this documentation easily accessible to all team members.

Unit testing with appropriate code coverage levels for the container application deployment platform environment (development, testing, production).

The policy “Unit testing with appropriate code coverage levels for the container application deployment platform environment (development, testing, production)” emphasizes the importance of thorough unit testing in all stages of the application development lifecycle. This policy aims to ensure that the code is not only functionally correct but also meets a defined standard of quality before it is deployed in any environment, be it development, testing, or production. Here’s how to implement this policy:

Implementing the Policy

  1. Define Code Coverage Targets:
    • Establish what constitutes “appropriate code coverage levels” for your project. This typically involves setting a percentage of the codebase that must be covered by unit tests (e.g., 80% coverage).
  2. Unit Testing Frameworks:
    • Implement unit testing using appropriate frameworks for your technology stack (e.g., JUnit for Java, pytest for Python, Mocha/Chai for JavaScript).
  3. Integration into Development Workflow:
    • Integrate unit testing into the regular development workflow. Developers should write unit tests as they write new code or modify existing code.
  4. CI/CD Pipeline Integration:
    • Configure your Continuous Integration (CI) pipeline to automatically run unit tests on every code commit or pull request. This ensures that tests are consistently run and passed before code is merged.
  5. Code Coverage Tools:
    • Use code coverage tools (like Istanbul for JavaScript, JaCoCo for Java, or for Python) to measure the percentage of code covered by tests. Configure these tools to report coverage metrics.
  6. Enforce Coverage Thresholds:
    • Set up your CI pipeline to fail the build if the code coverage falls below the predefined threshold. This enforces the policy and ensures attention to unit testing.
  7. Testing in Different Environments:
    • Ensure that unit tests are run in environments that closely mimic the production environment to catch any environment-specific issues.
  8. Regular Review and Adjustment of Coverage Goals:
    • Regularly review the code coverage goals and adjust them as necessary, especially as the project evolves and grows.
  9. Test Maintenance:
    • Regularly review and maintain the unit tests themselves to ensure they remain effective and relevant, especially after major code changes.
  10. Training and Documentation:
  • Provide training and documentation for the development team on best practices in unit testing and how to achieve the required coverage levels.
  1. Quality Gates in Deployment:
  • Implement quality gates in your deployment process that check for unit test completion and coverage levels before allowing code to progress to the next stage (especially to production).

Static application security testing (SAST) or source code analysis for custom source.

The policy “Static application security testing (SAST) or source code analysis for custom source” emphasizes the need to regularly conduct security assessments on the source code of applications. SAST tools are designed to analyze source code (or compiled versions of code) for potential security vulnerabilities without executing the programs. Here’s how to implement this policy:

Implementing the Policy

  1. Choose a SAST Tool:
    • Select a Static Application Security Testing tool that is suitable for your technology stack and integrates well with your development workflow. Popular SAST tools include SonarQube, Fortify, Checkmarx, and Coverity.
  2. Integrate SAST into the Development Process:
    • Integrate the SAST tool into your development process, ideally as part of the Continuous Integration (CI) pipeline. This ensures that code is automatically scanned for vulnerabilities as it is written and before it is merged into the main codebase.
  3. Analyze Custom Source Code:
    • Focus the SAST tool on analyzing custom source code written by your development team. Exclude third-party libraries or dependencies to the extent possible, as these are better handled by Software Composition Analysis (SCA) tools.
  4. Configure and Tune the SAST Tool:
    • Properly configure the SAST tool for your specific environment and use case. This might involve setting rules, thresholds, and exclusions to balance the depth of analysis with false positive rates.
  5. Review and Address Findings:
    • Regularly review the findings from SAST. Prioritize and address identified vulnerabilities in a timely manner.
  6. Training and Awareness:
    • Train developers on how to interpret and act on the results from the SAST tool. This helps in understanding security vulnerabilities and how to remediate them.
  7. Code Review Integration:
    • Encourage or require that findings from SAST are addressed or acknowledged during the code review process.
  8. Track and Monitor Progress:
    • Track and monitor the number and severity of vulnerabilities over time to assess improvements in code security.
  9. Continuous Updates and Improvements:
    • Regularly update the SAST tool and its configuration to reflect new security vulnerabilities, coding practices, and changes in the project’s technology stack.
  10. Policy Enforcement:
  • Implement policies that enforce the resolution of high-severity or critical vulnerabilities found during SAST before code can be merged or deployed.

Secure, non-privileged container build process.

The policy “Secure, non-privileged container build process” focuses on ensuring that the process of building container images is conducted in a secure manner and without granting unnecessary privileges to the build processes. This is crucial for minimizing the security risks associated with container image creation. Here’s how to implement this policy:

Implementing the Policy

  1. Use Non-Root Users in Dockerfiles:
    • When writing Dockerfiles, specify a non-root user for running the application. Avoid running the container as the root user unless absolutely necessary.
    • Example in a Dockerfile:
FROM node:14
# Create app directory
WORKDIR /usr/src/app
# Install app dependencies...
USER nonrootuser
  1. Minimize Base Image Content:
    • Use minimal base images (like Alpine Linux) that contain only the essential components needed to run your applications, thereby reducing the attack surface.
  2. Secure Build Contexts:
    • Be cautious about what files are included in the build context sent to the Docker daemon, as sensitive files in the build context can inadvertently end up in the image.
  3. Use BuildKit or Similar Tools:
    • Utilize Docker BuildKit or similar tools that provide advanced features for security, performance, and scalability. BuildKit helps in efficiently managing dependencies and secrets without exposing them.
  4. Scan Images During Build:
    • Integrate security scanning into the build process. Tools like Trivy, Clair, or Anchore can be used to scan images as part of the CI/CD pipeline.
  5. Avoid Installing Unnecessary Packages:
    • When writing Dockerfiles, avoid installing unnecessary packages that could increase the vulnerability surface.
  6. Build-Time Secret Management:
    • Manage secrets securely during the build process. Avoid hardcoding secrets in Dockerfiles or source code. Use build-time secret management features provided by Docker or external secret management tools.
  7. CI/CD Pipeline Security:
    • Configure your Continuous Integration (CI) system to run container builds in a secure environment. This includes running CI runners or agents with least privilege.
  8. Regularly Update and Patch:
    • Keep your base images and all dependencies up to date with the latest patches and updates.
  9. Audit and Compliance:
  • Regularly audit your container build process for compliance with these best practices and organizational security policies. is an independent recruitment website launched in 2023 on a mission to match impactful people with meaningful organizations

Hi! My name is Carlos and I’ve been working in tech for the past 9 years.

I built this website to share my passion for recruitment and tech.

Clicking the heart tells me what you enjoy reading. Social sharing is appreciated (and always noticed).

That’s it. That is my pitch for you to stick around (or browse the site as you please).

If you want to get in contact with me, reach out to me via my socials đź™‚

“Think of me as the ‘Consumer Reports’ for Impactful Talent.”

Exclusive insights on roles directly in your inbox.