Phew, the title of this post alone sounds like it could be quite a lot to deal with!
So what is DevOps? DevOps is simply the blending of infrastructure operations processes and software development to enable faster changes to business applications/technology. These processes share a lot of ideology with the Agile & Lean camps but are more fundamentally trying to bridge the traditional divide between the development world and the IT operations/Service management teams.
In practice DevOps can mean a lot of different things to a lot of different people and sometimes it can be difficult to apply compliance requirements without getting a good understanding of what is possible.
Terms such as 'treat your code as infrastructure' can often scare the life out of traditional auditors along with the fear that with rapid release and change comes rapid loss of control. These shouldn't be scary but should be embraced and understood. In audit parlance these processes can become embedded, configurable application controls that require less substantive audit sampling and allow the focus to be on their effectiveness at providing security control.
DevOps environments typically make heavy (think obsessive!) use of automation tools to enable rapid change and release processes to be possible at large and frequent scale. This is typically where the confusion starts to begin when evaluating these environments for security and compliance purposes. Typical service management controls such as change management on the surface may appear to have been cast aside in the rush to 'be DevOps'.
This rush to implement tooling can often lead to the underlying processes being weak or ill conceived. However this is common in other disciplines too. Poor planning = poor performance.
DevOps done well can bring a great set of tools and capability for building secure, scalable and compliant environments. Building on source control, streamlining change control and building dependency on the tools authentication and access control can quickly be used to demonstrate the control requirements of many compliance frameworks including the PCI DSS. Just doing things faster or without lots of paper forms and signatures on doesn't equate to non-compliance.
The implementation of PCI DSS requirements 2 and 6 can be rapidly transformed using a DevOps approach. If we look at requirement 2 as being primarily focused on hardened configuration management traditionally seen as an 'Ops' area, while Requirement 6 focuses on change management and software development.
There is nothing fundamentally in these requirements (or in other areas of the DSS) that prevents a DevOps environment being used to support and implement PCI compliance. Whilst the security and compliance mandate might tweak certain implementation decisions most of the tools marketed for 'DevOps' support building workflows that can be used for approval / review decisions and capture/log the necessary approval processes to support compliance. As the level of automation increases so can the ease of which compliance requirements be met.
Recently I worked with a client that had invested heavily in building their dev-ops tooling but they had built in PCI requirements as part of this process so also incorporated automation of documentation production too. Their focus was and still is to automate as much as possible into the release process to minimize the failure of an activity. Every time a new release was pushed all configuration documentation was also updated automatically (supporting requirement 2). This particular client used a software issue and tracking tool that could be used to demonstrate management approval for changes as well as to show that code review processes had been followed. As they continued to improve they were investigating automation of their code review processes so that static analysis tools were orchestrated immediately after changes were approved as part of the build process.
One of the biggest challenges they faced initially was the size of their team, they were small and specialist and in the past had struggled with creating segregation of duties between their test/production systems. Moving to dev/ops helped with this significantly. No developers were required to have access to production systems in any manner as the build and release process was entirely orchestrated by tools with an approval workflow. The tools were the only thing with the ability to push to their production systems and the workflow done under management approval. These tools were treated the same way as other in-scope systems but the overhead from this was so minimal that it enabled them meet security requirements without complicated manual processes and multiple sets of access permissions.