Hello again, infrastructure pros! I’m back to talk more about staying sane and secure in the cloud. Back in August, we examined using Source Control Management (SCM) to secure your infrastructure. But, that’s just one part of the story.
In the first part of this series, Maintaining Security and Sanity at Cloud Speed: Part One, we looked at why infrastructure as code, provisioning scripts — and every script used by operations need to be stored in a code repository. But there’s more to staying secure and sane than getting to know and use SCM.
What are Pull Requests and Peer Reviews?
I told you I’d be back to talk about pull requests and peer reviews of your code. Here I am! It’s a topic I enjoy. Ready to learn more? Let’s get this new discussion about the benefits of DevOps and microservices started!
If you’re unaware or unfamiliar with the terms “pull requests” and “peer reviews,” or if you have no idea why they are relevant to what you do, then you’ve come to the right place. These concepts affect everyone who works in the current, fast-paced, blink-and-you-miss-it cloud world, and can really help you implement clean, secure code.
If you have a script or software that, "makes the magic happen," and that item already resides in SCM for safekeeping (see last month’s post), then you’re ready to level up to performing peer code reviews. If you don't have this valuable process in place, there’s no better time than now to launch these reviews.
In my last blog, I talked about the separation of duties in code writing and management. Here’s why; a pull request must occur in order to kick off a formal peer review of your code and code changes. You can’t have a review if you don’t have a pull request. And you need a fresh set of eyes to do the review. First, however, let me back up for a second to clarify a few things.
A pull request is, as the name suggests, a request to merge code changes from one file into another. For example, if I add a line of code to your application, I submit a pull request so I can add my input. As part of that request, I must document what I am adding and why I want it merged. Perhaps there’s another reason I want to make a code change. Regardless of what the reason is, I must document the what and why at the time of the request.
Ideally, creating a pull request will launch an automated test that checks for syntax, style and security, such as the OWASP Top 10. Once that automated test passes and I have created the request, it triggers the next step, the peer review. Should the automated test fail, I then know what I need to fix before someone reviews my code.
During the peer review process, someone other than the code's author reads the proposed changes and offers suggestions for changing the code. These reviews should be performed as soon as possible; this enables the author to be able to make changes while the coding is still fresh in their mind. The reviewer can also deny the changes if it’s deemed appropriate.
Why Could Peer Reviewers Deny Code Changes?
Reviewers might deny changes if they believe these changes could be open security vulnerabilities. Or maybe a change could potentially cause a crash, or at least be considered inefficient. Any of these issues could create a negative user experience for your customers or coworkers.
If your review doesn’t have any red flags and the reviewer is comfortable with the proposed changes, the pull request will be approved. This allows the code to be merged. Once that occurs, it’s safe to deploy the change for use by your end users or customers.
You’ll reap lasting benefits from implementing these processes. You’ll gain an auditable path of when and where things changed within the code. This makes rolling back to previous versions much easier even if they are in code repositories.
Whenever you can get a second set of eyes, including those of your managed services provider, on a potentially dangerous change, you can make it more secure. Sure, it takes a few additional steps, but ultimately, it’s a winning proposition for everyone.
