Compliance, both regulatory and self-imposed, is another area where the shift-left movement has taken hold. By building compliance into your workflow with compliance as code methods, your team can save time while producing secure, low-risk code.
What is compliance as code?
Compliance as code methods ensure that the correct regulatory or company compliance requirements are fulfilled with zero-touch on the path to production. It builds compliance into development and operations.
The utilization of compliance as code tools enable stakeholders to ensure that production procesesses are compliant by means of defining how resources must be configured. Such a structure often allows these tools to automatically adjust resources into a compliant state in order to meet these pre-defined compliance requirements.
This type of minimal-friction compliance is a crucial solution for large enterprises – especially those subject to complex regulation (such as enterprises operating in healthcare or financial services). By building compliance into the DevOps lifecycle, you will streamline the workflow and save developers valuable time during review and testing.
How to impliment compliance as code
As Jim Bird wrote for O’Reilly, compliance as code policies must be defined up front, and will bring together management, compliance, internal audit, PMO, and infosec leaders. This group will work together to define rules and control workflows. Management also needs to understand how operational and other risks will be handled throughout the pipeline.
How your company does establish compliance as code policies will depend on how your team is structured but regardless of how your teams interact, transparency is required. To ensure that information is shared and decisions are made collaboratively, consider establishing the following guidelines:
- Peer reviews: The first review cycle for larger changes should be manual, to ensure no changes are made without at least one other person verifying the change. Reviewers can be assigned randomly to ensure the quality of review.
- Static application security testing: Static (or white box) testing should be done for every code change, in addition to manual reviews.
- Subject matter expert reviews for high-risk code: For code that the management team defines as high-risk (such as security code), changes should be reviewed by a subject matter expert.
- Regulated access controls: Management should keep access in check, both so that changes aren’t made by a single engineer, and so that every change flows through the workflow and can be reviewed by anyone with access to the dashboard.
Enhance technology with culture
Technology and processes will only work if your team cultures are aligned with your goal – and culture starts at the top. Team leaders should promote and exemplify a security-first mentality and openness to collaborative change. This will be a new way of thinking for some, but it will help teams adopt the shift-left trend, ultimately saving everyone time and reducing business risk.
Compliance and open source
In 2015, The Linux Foundation found that more than 60% of companies build products with open source software, but more than half of those companies don’t have formal procedures in place to ensure their software complies with open source licenses and regulations. Companies should create a free and open source software (FOSS) compliance program not only to abide by copyright notices and license obligations, but also to protect company IP and third-party source code from disclosure.
How we do compliance at GitLab
We began our formalized compliance program towards the end of our Series C funding round, which was fairly early compared to other businesses of our size. The benefit of starting early was that we were able to implement security controls while we were still developing and evolving our operating processes, instead of retrofitting security to the business. The key decision in our approach was choosing between independent or aggregate security controls: We chose the aggregate route, leveraging Adobe’s CCF, rather than implementing industry frameworks individually. This allowed us to mitigate overlapping asks to GitLab teams, which enabled an agile and efficient program standup, and gave the compliance group internal credibility.
Compliance as code provides benefits across your ecosystem
There are benefits to everyone from the developer to the third-party auditor when compliance is baked into code from the beginning. These benefits include:
- Time saved: Your teams will spend less time passing code fixes back and forth.
- Compliance transparency: Management will understand where and how your software abides by compliance requirements.
- Routine reporting streamlines auditing: Reports throughout the DevOps lifecycle provide documentation and proofs of record that will help management track and streamline any regulatory audit procedures.
Cover image by Hack Capital on Unsplash
“How to get started with compliance as code” – Vanessa Wegner
Click to tweet