savvy-devsecops

Projects that follow the best practices below can voluntarily self-certify and show that they've achieved an Open Source Security Foundation (OpenSSF) best practices badge.

If this is your project, please show your badge status on your project page! The badge status looks like this: Badge level for project 7960 is in_progress Here is how to embed it:

These are the Gold level criteria. You can also view the Passing or Silver level criteria.

        

 Basics 0/5

  • Identification

    Best Practices for GitHub Native DevSecOps Pipeline Implementing DevSecOps best practices for CI/CD (Continuous Integration/Continuous Delivery) in GitHub involves integrating security practices throughout the software development lifecycle. This ensures that security is not treated as an afterthought but is an integral part of the development process. Here's a description of GitHub native DevSecOps CI/CD best practices:

    1. Infrastructure as Code (IaC) Security: Utilize GitHub's infrastructure as code capabilities to enforce security measures in the deployment pipeline. Use tools like Terraform or GitHub Actions to ensure that infrastructure deployments are secure and adhere to best practices.

    2. Automated Security Testing: Integrate automated security testing into the CI/CD pipeline. Use tools like SonarQube, Snyk, or GitHub-native security tools to scan for vulnerabilities, malware, or code flaws as part of the build process.

    3. Code Analysis and Review: Encourage secure coding practices through code analysis and review. Leverage GitHub's code scanning and pull request review features to identify and fix security vulnerabilities early in the development process.

    4. Policy Enforcement with GitHub Actions: Enforce security policies using GitHub Actions to automate checks for compliance, code quality, and vulnerability scanning. Use pre-configured workflows to ensure that all code changes meet the organization's security standards.

    5. Container Security: Implement container scanning tools like Docker Security Scanning or GitHub container scanning to detect vulnerabilities within the container images before deployment. Make sure that only secure and approved container images are used in the CI/CD pipeline.

    6. Secret Management: Manage secrets securely by utilizing GitHub's native secret management solutions. Encourage the use of environment variables and GitHub Secrets to store sensitive information securely, reducing the risk of exposure during the CI/CD process.

    7. Access Control and Permissions: Enforce access control and permissions for repositories and CI/CD pipelines to ensure that only authorized personnel have access to sensitive information and critical deployment processes. Implement GitHub's access management features to define roles and permissions for different stakeholders.

    8. Incident Response and Monitoring: Implement monitoring and logging solutions within the CI/CD pipeline to track and analyze security incidents in real-time. Use tools like GitHub Security Advisories and Security Insights to stay informed about security vulnerabilities and take prompt action when necessary.

    9. Continuous Learning and Improvement: Foster a culture of continuous learning and improvement by regularly updating security measures, conducting security awareness training, and staying informed about the latest security threats and best practices. Encourage developers to stay updated with the latest security guidelines and tools.

    By following these GitHub native DevSecOps CI/CD best practices, organizations can build a robust and secure development pipeline, ensuring that security is integrated seamlessly throughout the software development lifecycle.

  • Prerequisites


    The project MUST achieve a silver level badge. [achieve_silver]

  • Project oversight


    The project MUST have a "bus factor" of 2 or more. (URL required) [bus_factor]


    The project MUST have at least two unassociated significant contributors. (URL required) [contributors_unassociated]

  • Other


    The project MUST include a license statement in each source file. This MAY be done by including the following inside a comment near the beginning of each file: SPDX-License-Identifier: [SPDX license expression for project]. [license_per_file]

  • Public version-controlled source repository


    The project's source repository MUST use a common distributed version control software (e.g., git or mercurial). [repo_distributed]

    Repository on GitHub, which uses git. git is distributed.



    The project MUST clearly identify small tasks that can be performed by new or casual contributors. (URL required) [small_tasks]


    The project MUST require two-factor authentication (2FA) for developers for changing a central repository or accessing sensitive data (such as private vulnerability reports). This 2FA mechanism MAY use mechanisms without cryptographic mechanisms such as SMS, though that is not recommended. [require_2FA]


    The project's two-factor authentication (2FA) SHOULD use cryptographic mechanisms to prevent impersonation. Short Message Service (SMS) based 2FA, by itself, does NOT meet this criterion, since it is not encrypted. [secure_2FA]

  • Coding standards


    The project MUST document its code review requirements, including how code review is conducted, what must be checked, and what is required to be acceptable. (URL required) [code_review_standards]


    The project MUST have at least 50% of all proposed modifications reviewed before release by a person other than the author, to determine if it is a worthwhile modification and free of known issues which would argue against its inclusion [two_person_review]

  • Working build system


    The project MUST have a reproducible build. If no building occurs (e.g., scripting languages where the source code is used directly instead of being compiled), select "not applicable" (N/A). (URL required) [build_reproducible]

  • Automated test suite


    A test suite MUST be invocable in a standard way for that language. (URL required) [test_invocation]

    Warning: URL required, but no URL found.



    The project MUST implement continuous integration, where new or changed code is frequently integrated into a central code repository and automated tests are run on the result. (URL required) [test_continuous_integration]

    Warning: URL required, but no URL found.



    The project MUST have FLOSS automated test suite(s) that provide at least 90% statement coverage if there is at least one FLOSS tool that can measure this criterion in the selected language. [test_statement_coverage90]


    The project MUST have FLOSS automated test suite(s) that provide at least 80% branch coverage if there is at least one FLOSS tool that can measure this criterion in the selected language. [test_branch_coverage80]

  • Use basic good cryptographic practices

    Note that some software does not need to use cryptographic mechanisms. If your project produces software that (1) includes, activates, or enables encryption functionality, and (2) might be released from the United States (US) to outside the US or to a non-US-citizen, you may be legally required to take a few extra steps. Typically this just involves sending an email. For more information, see the encryption section of Understanding Open Source Technology & US Export Controls.

    The software produced by the project MUST support secure protocols for all of its network communications, such as SSHv2 or later, TLS1.2 or later (HTTPS), IPsec, SFTP, and SNMPv3. Insecure protocols such as FTP, HTTP, telnet, SSLv3 or earlier, and SSHv1 MUST be disabled by default, and only enabled if the user specifically configures it. If the software produced by the project does not support network communications, select "not applicable" (N/A). [crypto_used_network]


    The software produced by the project MUST, if it supports or uses TLS, support at least TLS version 1.2. Note that the predecessor of TLS was called SSL. If the software does not use TLS, select "not applicable" (N/A). [crypto_tls12]

  • Secured delivery against man-in-the-middle (MITM) attacks


    The project website, repository (if accessible via the web), and download site (if separate) MUST include key hardening headers with nonpermissive values. (URL required) [hardened_site]

    Found all required security hardening headers.

    Warning: URL required, but no URL found.


  • Other security issues


    The project MUST have performed a security review within the last 5 years. This review MUST consider the security requirements and security boundary. [security_review]


    Hardening mechanisms MUST be used in the software produced by the project so that software defects are less likely to result in security vulnerabilities. (URL required) [hardening]

  • Dynamic code analysis


    The project MUST apply at least one dynamic analysis tool to any proposed major production release of the software produced by the project before its release. [dynamic_analysis]


    The project SHOULD include many run-time assertions in the software it produces and check those assertions during dynamic analysis. [dynamic_analysis_enable_assertions]


This data is available under the Creative Commons Attribution version 3.0 or later license (CC-BY-3.0+). All are free to share and adapt the data, but must give appropriate credit. Please credit Nishkarsh Raj and the OpenSSF Best Practices badge contributors.

Project badge entry owned by: Nishkarsh Raj.
Entry created on 2023-10-16 11:06:43 UTC, last updated on 2023-10-17 06:20:21 UTC.

Back