When git was created, it was designed as a code collaboration tool with the following goals:
- Simple design
- Strong support for non-linear development (thousands of parallel branches)
- Fully distributed
- Able to handle large projects like the Linux kernel efficiently (speed and data size)
The practice of DevSecOps brings security into DevOps processes. A critical part of that is automating and embedding security into version control systems (VCS) like GitHub, GitLab, and BitBucket, and continuous integration (CI) tools that integrate with VCS systems.
Ready to take your VCS to the next level? Here are seven best practices to keep in mind.
1. Security should be agile, too
The first tenant of git is speed. That’s also true of any testing and feedback provided in your VCS. Once an engineer creates a pull request or merge request (PR/MR) and moves on to their next task, the clock starts ticking for the window when feedback will be easiest to incorporate. Automated security testing should take no longer than it takes to grab a cup of coffee from the barista downstairs when you remember to order ahead (it happens!).
Similarly, peer and security reviews need to happen as soon as possible after the PR/MR is opened. Agile methodologies, where smaller chunks of code are added at a time, make this more achievable.
2. Audit, improve, and block (in that order)
We all want to be as secure as possible, but adding a new tool with a laundry list of new policies in hard fail mode is a good way to upset your fellow engineers.
Start by auditing your codebase for all security issues. Provide that list of misconfigurations to your various teams and begin to tackle them. Use a baseline as a way to only fail on new misconfigurations and begin to address the backlog of existing issues. Once you are satisfied with the current state, move to add blocking rules that block merging code that doesn’t pass automated tests.
3. Include clear prioritization
Receiving a long list of security issues can be overwhelming. Ensure that all priorities are clear by providing inline risk ratings and any additional relevant information, such as security frameworks that apply to your business like PCI or HIPAA. This makes it easier to overcome cognitive biases that make getting started difficult. Figure out which issue to tackle first, even if all are required to pass to merge the code.
4. Tune your settings to fit your use case
When adding those blocks, it’s not a one size fits all solution. Git and VCS tools are designed for non-linear development and large projects. The settings you have for one repository may not fit another. For mission-critical applications handling sensitive data, for example, even low severity issues may not be acceptable. For purely internal-facing applications, maybe only critical severity issues need to be addressed, but medium and high severity issues should be surfaced to engineering teams for awareness. Tune your security tools per use case.
5. Minimize context switching when providing feedback
Another goal for git and VCS providers is simplicity. Adding another user interface to a development flow, no matter how well designed, adds unnecessary overhead. Ensure that automated and human feedback shows up in the VCS provider as PR/MR comments. This also helps highlight the exact line where the security issue is introduced, making repairs that much easier. If you do have a separate UI for things like an aggregated view, keep it similar to the flow of a VCS to minimize the time it takes to grok the tool.
6. Provide clear fix guidance and fix suggestions
Any feedback provided by either automated or manual reviews should include clear, actionable remediation guidance. Until AI is perfected, automated tools and QA will not know your code as well as you do, but they can provide as much guidance as possible. If there is a known fix, provide that fix inline within the review or as a commit to the PR/MR. When a known fix is not available or is too complex, provide as much additional guidance as possible.
7. Create open collaboration
At the end of the day, VCS are collaboration tools. Any feedback provided should not be done in isolation. Encourage open discussions on best practices and ways to improve code between developers and QA reviewers.
For automated code reviews, use them as an opportunity to collaborate. We’ve seen customers use automated comments as a starting point for discussions. Say the bot catches that you forgot to add logging. You can spark up a discussion about how your organization prefers to set up logging, such as a central bucket.
Bonus: Encourage continuous education and improvement
Adding DevSecOps to your VCS is an opportunity to improve the security of your applications before they are deployed. It’s also one of the best ways to learn how to improve your code. If you’ve ever taken a class that was all theory and tried to apply that knowledge, you know how difficult it is to match the real world with toy problems. Security education platforms, like Secure Code Warrior, are great at providing learning based on your actual code. By identifying areas for improvement and explaining the why and how using code you are familiar with, you absorb that information much easier.
Adding automation and security to VCS provides a fast, scalable way to provide actionable feedback inline, increasing the chance for repairs. Bridgecrew is designed especially with automation in mind. Our PR comments, Code Reviews, and Projects page may look and feel familiar because they are purposefully designed with VCS workflows in mind. Sign up for Bridgecrew for free and try your first VCS integration to see how DevSecOps can accelerate development.