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

FROM node:16 as builder
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build

FROM node:16-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
CMD ["node", "dist/main.js"]

# Build stage
FROM node:16 as builder
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build

# Distroless stage
FROM gcr.io/distroless/nodejs:16
COPY --from=builder /app/dist /app
WORKDIR /app
CMD ["main.js"]

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:
   • Integrate your version-controlled registries with your CI/CD pipelines. Ensure that when new versions of container images or security artifacts are created, they are automatically versioned and stored.
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 Coverage.py 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.

11. 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.