The GitHub Security Lab audits open source projects for security vulnerabilities and helps maintainers fix them. Recently, we passed the milestone of 500 CVEs disclosed. Let’s take a trip down memory lane with a review of some noteworthy CVEs!
August 8, 2023: We’ve added a section with two example tools for fuzz testing.
With the interconnectedness of modern software and the different types of code, you’ll often need to use numerous application security tools, each purpose-built to detect a specific kind of risk from a specific portion of your software. When integrating multiple tools into your workflow, you may find yourself trading off productivity–and collaboration–for security. That’s because different tooling, with different user experiences, can create context switching and inconsistency across how you test.
At GitHub, we don’t believe in sacrificing your experience, productivity, or collaboration for security. GitHub Advanced Security (GHAS) embeds security testing into your familiar workflow, helping you to prevent and fix vulnerabilities and secret leaks. With GHAS, you can also seamlessly integrate open source and third-party testing tools in the same workflow as the native GitHub security solutions. This means that on every pull request, you can automate security testing and cohesively display results in the same format that GitHub results are delivered in, creating continuity in your developer experience.
To help you secure your code, most GHAS security features are free on all public repositories and are offered as an add-on to protect your private repositories. Meaning you can use GHAS to analyze your code for leaked credentials with secret scanning, identify known insecure coding patterns with CodeQL, and find vulnerabilities in your supply chain using Dependabot and Dependency review–all while having visibility into findings with security overview. To extend or complement these GitHub-native capabilities, you can choose from more than 60 integrations to open source or third-party application security tools spanning SAST, Mobile, SCA, DAST, API, or container scanning out of the box. This empowers you to choose the best tool for you and your software without sacrificing a robust security orchestration experience.
Your AppSec program will consist of a variety of tools, each purpose-built for a specific type of risk. The combination of tools you’ll need will depend on your unique code. No matter which tool you select, once you’ve automated your security testing with GitHub Actions, every pull request will be tested automatically. If a security finding is detected, it will be surfaced to you directly in the pull request, giving you the same user experience as GitHub’s built-in security solutions. To help you get started selecting what tool is right for your team we’ve mapped out common testing types and why you may use them.
Note: all third-party tools in this section are provided as an example, not as a formal recommendation from GitHub; please research any tool based on your unique needs before selecting that as your tool of choice.
Static Analysis (SAST)
To ensure the code your writing is secure, GitHub has a native SAST tool, CodeQL. CodeQL is a semantic code analysis engine that powers GitHub code scanning and allows you to prevent and fix security vulnerabilities in your source code. CodeQL will identify the OWASP top-10, hardcoded credentials, and other types of insecure coding patterns.
If you use languages, like Rust or Elixir, that are not currently supported by CodeQL or want to extend the depth of your mobile testing. You can extend your coverage with open source or third-party tooling, such as Sobelow or NowSecure via a GitHub code scanning with Github Actions. The integration experience provided by GitHub code scanning and actions means you can rapidly adopt new languages and frameworks ahead of support within our native tools while maintaining your security posture and providing a consistent experience for developers and security teams in the pull request.
To ensure you haven’t accidentally exposed a credential in your code, issue, or comments, Github has a native secret detection tool. GitHub’s secret scanning helps you identify leaked credentials in your code and helps you prevent new secrets from being introduced. Secret scanning identifies API tokens from more than 100 major cloud service providers and developer tools. With secret scanning’s push protection capabilities you can proactively prevent tokens from entering your repository. You can also provide custom regular expressions, which helps to identify personally identifiable information, SSH keys, payments information, or internal API tokens that are not detected by default.
Software Composition Analysis (SCA)
To keep your software supply chain secure, GitHub has native supply chain security features, Dependabot, and Dependency review. Dependency review helps you understand dependency changes and the security impact of these changes at every pull request. Dependabot secures your supply chain by identifying dependencies and their vulnerabilities, and suggesting ways to fix, patch, or update them. You can configure Dependabot to evaluate the licenses of new dependencies, block new dependencies that have known vulnerabilities, and prioritize vulnerabilities based on whether or not your application makes a call to the vulnerable function.
If you are deploying in containers, the container image will include operating system software included in the docker layers that could come from a public container registry like DockerHub. These container images may have vulnerabilities; tools like Trivy from Aquasec and Grype from Anchore are open source tools you can use to scan a container image for security vulnerabilities. With GitHub code scanning and actions, you can integrate these into the GitHub code scanning workflow, providing a consistent experience for developers and security teams in the pull request.
Infrastructure as code scanning
Depending on your architecture you may want a tool that can evaluate your Kubernetes configuration for vulnerabilities, or that can scan infrastructure as code templates like Terraform or Azure Resource Manager templates. Tools like Kubesec and tfsec can help identify configuration errors within your infrastructure and can be integrated via GitHub code scanning and actions to provide a consistent experience for developers and security teams in the pull request.
Dynamic application security testing (DAST)
Some vulnerabilities can only be found when an application is executed. Once your application is in staging or QA, you can use a DAST solution to get an outside-in view of your application. It attempts to safely exploit thousands of attack vectors to find vulnerabilities within your web assets. Tools like StackHawk and OWASP Zap perform dynamic application testing and report their results back to developers using the GitHub code scanning API.
Note: dynamic application testing results do not always fit neatly within the SARIF format; for example, dynamic alerts do not have line numbers or file names associated with the findings. For now, DAST alerts will return with deep links to the DAST provider’s platform which can display DAST alerts more robustly. While not perfect, this still provides a consistent context and alert surfacing.
Similar to DAST, once your application is deployable, you may want to conduct API security testing. You can integrate tools via GitHub code scanning and actions (like 42Crunch) to analyze APIs within the application statically and dynamically, or a DAST solution that has the ability to find and test APIs, like StackHawk and OWASP Zap.
Fuzzing is a runtime testing technique that involves sending invalid, unexpected, or random data to a program in order to test its behavior and identify vulnerabilities. It is typically used to find bugs that cause crashes or other abnormal behavior. Some of the techniques used in fuzzing include mutation-based generation and directed generation. Both of these techniques can help identify vulnerabilities and other issues that may not have been detected through other testing methods. Look to tools like Google’s ClusterFuzzLite and OWASP Zap Fuzzing for strong open source fuzz testing.
Once you select the right tools for your organization, you can integrate open source or third-party security tools into your GitHub workflow in just a few clicks with GitHub Actions. To add a new testing type to your development pipeline, navigate to the Security tab, select Code Scanning under the Vulnerability Alerts navigation heading, then click the Add Scanning Tool button. You’ll land on the Choose a workflow screen where you can choose open source and third-party security scanning tools to automate testing directly into your workflow. To help you get started, GitHub offers 2,000 free GitHub Actions minutes and free code scanning for all public repositories.
You can also use a third-party CI tool like Jenkins or TeamCity. Check out this best practices post to learn more. If you don’t find your scanning tool of choice, GitHub code scanning can support any application security testing tool that delivers findings in the JSON SARIF format.
Once you’ve automated your security testing with GitHub Actions, every pull request will be tested automatically. If a security finding is detected, it will be surfaced to you directly in the pull request, giving you the same user experience as GitHub’s built-in security solutions. From here, you can take action to remediate, collaborate with your peers with built-in code review, or flag results to your security team.
For security teams, engineering leaders, and developers who work across hundreds–or even thousands–of repositories, security overview provides a centralized view of risk across your applications. With security overview, you can easily see what repositories are currently being tested by which security solutions, the vulnerabilities and risks associated, then take action without leaving the reporting view.
To view the security overview dashboards, select the Security tab from within your organization. From here, you can drill in at the ‘Enterprise,’ ‘Organization,’ or ‘Repository’ level and filter by team, severity, tool, rule, branch, or alert type, or automatically enable testing directly from security overview if a security feature hasn’t been turned on. To specifically see results from open source or third-party security tools, select the Code scanning tab.