I would like to continue exploring the PCI-DSS 3.0 requirements and their relevance for Git administration. Development tools and processes were not in the focus of the PCI-DSS 3.0 before, but in the 3.0 version of the standard, there are some implications.
In my previous two blog posts I shared a story of my friend who is currently exploring the possibility of migrating from Subversion to Git and is in the process of understanding the impact of PCI-DSS on their SCM technology choice and the project scope. As their project progressed, they found that what they initially thought to be a simple project introduces many potential PCI risks and they need to thread carefully.
In the last post, I shared my insight on the requirement 6 of the standard and how it would impact the automation of patch distribution. I received many questions about another aspect of the same requirement related to code reviews, and I would like to share some ideas with you in this regard. It is an interesting area that definitely deserves a detailed post (or maybe even more than one), as it brings up an important topic of compliance scalability.
As my friend’s project progressed, they interviewed stakeholders across the company to capture and document the additional business requirements that their Git infrastructure would need to support. They found that as they grow their business, they would need to open up their hosted environments to the implementation partners and would need to create a “public” code repository where partners can develop custom code. This presented a very interesting challenge for them. Right now only the company’s developers and contractors have access to the Git environments. Once they implement the partner program, developers from outside of the company would be able to modify the code, implement changes, and promote them into production in particular environments.
This means that their code review procedures needed to be extended to cover external stakeholders as well as their own employees. Requirement 6.3.2 states:
“Review custom code prior to release to production or customers in order to identify any potential coding vulnerability (using either manual or automated processes) to include at least the following:
- Code changes are reviewed by individuals other than the originating code author, and by individuals knowledgeable about code review techniques and secure coding practices.
- Code reviews ensure code is developed according to secure coding guidelines
- Appropriate corrections are implemented prior to release.
- Code review results are reviewed and approved by management prior to release.”
At the first sight, the requirement is straightforward and makes a lot of sense. Moreover, they already have stringent code review policy. The challenge the team faced was not so much in meeting the compliance requirements, but in producing a reliable proof that the code review policy is being followed. Now, when they do their internal code reviews, their developers work with a code review form; this document is sent to all the reviewers by email. Once the reviewers complete the process, the code can be merged into the master branch. The reviewers include their comments in the form and return the document via email to the change author and the approving manager, so the company has a proof of compliance. All is well, but the only trouble with the process is that it is manual. It might work well when the number of people is small and they all work for the same company. But when the company needs to scale their compliance, the manual process can potentially become a herculean task for everyone involved and may take a lot of time and effort. Plus, it is not as reliable anymore. In order to scale across hundreds of internal and external developers, the sign-off process must become digitally enforceable, which calls for a lot more automation than the company currently has.
In my last blog we discussed that the technology selected for code version control can play a major role in catching non-compliant change to ensure that all conditions regarding code quality and compliance are met before a commit is merged into the master branch. The same technology is also very useful for scaling compliance when you quickly produce a proof of compliance across large population of internal and external developers and reviewers who may follow different code review techniques.
I encourage you to take a look at CollabNet’s Git backend, Gerrit, and our code quality gate wizard feature for Gerrit. It comes with a collection of predefined policies letting you graphically design your own quality gates. It is excellent for code review process automation. What makes the CollabNet wizard especially relevant for the requirement 6.3.1 is the fact that it comes with pre-defined policy for:
When the audit time comes, it will be a small, effortless project for your company. All you have to show your auditor is the code gates. No more emails and manual forms. Done! If you are interested in learning more about how to setup these enforceable policies in your Git/Gerrit environment, we have an excellent blog post written by Johannes Nicolai on this topic.
Another area that I should probably also mention in relation to scaling your compliance is process templates in TeamForge. Although not directly PCI-related, it is important for avoiding surprises. TeamForge helps you achieve consistency of your processes across all of your projects that have PCI DSS requirements. Imagine being able to show your auditor that you follow the same rigorous code review process for all your production code, no matter if you are developing a major new feature or implementing a small code fix. Auditors love consistency!
In my next blog, we will discuss other aspects of compliance scalability and why they are often overlooked by some organizations.