The challenges we’re currently experiencing will eventually leave the public consciousness, but their effects on the economy and on business cultures and operations are likely to be felt for at least the next decade. Now more than ever, organizations need to automate business processes to improve resilience, enable new services to support customers, and drive digital transformation to allow longer term transitions to remote working. And while some of these efforts to digitize won’t endure, most will: we are at the start of an acceleration of the digital phase shift, and software development is at the heart of that transformation.
Not easier said than done
Developing secure software is more critical than ever, but it’s a significant understatement to describe this as “easier said than done.” For most organizations, embedding security into software development is like achieving a state of nirvana. But why is “secure by design” so difficult to achieve?
One major challenge is centralizing the governance of the separate functions as required in software development — including security.
In many modern application security programs, there are several teams dedicated to specific functions. For example, you might have one team for Static Application Security Testing (SAST), one team for Dynamic Application Security Testing (DAST), and one team for Software Composition Analysis (SCA). When a team of developers works on an application, they coordinate with each of these teams individually to ensure security tests are run against the application.
Centralizing these individual teams generates significant benefits.
- Visibility: centralizing live information into a single location that can be viewed by all parties on-demand
- Integrity: enabling change tracking to ensure historical changes are legitimate and sensible
- Consistency: maintaining a universal format leveraged by all parties.
While the business takes stock of its processes in the new reality, security teams have a unique opportunity to integrate with the centralization of development operations, using Continuous Integration and Continuous Delivery (CI/CD) pipelines.
Pushing for CI/CD pipelines
CI/CD pipelines allow development teams to centralize development processes without overhauling the organization’s internal structure. In this way, CI/CD pipelines deliver all three of the aforementioned benefits to security teams: visibility by displaying the security checks integrated with the pipeline to developers and security members alike; integrity by tracking changes to the pipeline configurations and existing integrations; and consistency by ensuring each application, and even each application build, goes through the same process for security readiness.
In many high performing organizations, CI/CD pipelines are already a mainstay of DevOps methodologies at work. If your company has yet to implement one, you may not have to worry about financials — open source, CI/CD pipeline tools are available free of cost.
Organizations may face challenges when trying to integrate security into CI/CD pipelines, and the team may have to address these by driving home a few key principles. By following these principles, however, organizations can reduce the friction that comes with process modernization and transformation.
All changes create some resistance. Integrating security checks into the CI/CD pipeline means security teams will have to change the way they operate. These teams will no longer directly oversee and conduct security tests, but rather will oversee the integration with the pipeline and empower developers to administer the tests automatically as they trigger new builds, as per the DevOps mantra “You build it, you own it.”
The benefits that come with this shift are clear. The security team can scale its operations more efficiently and focus its attention on program improvements rather than operations, in line with the Phoenix Project’s guidance to prioritize improvement of daily work over doing daily work.
But it’s a significant change, nonetheless, and individuals may have a difficult time adjusting to the new model of application security delivery. Leadership must continually push a positive mentality around this shift and communicate the importance of the benefits the new structure provides.
Although it can be tempting to zealously engage in new projects to improve the entire organization, a more successful approach breaks up the end goal into a series of smaller milestones. Developers in a global media-services provider claim this itemization as one of the key reasons their world-renowned security suite still exists today.
When security teams plan to introduce their tools into a CI/CD pipeline, these integrations should be done in an orderly and incremental manner. The SAST, DAST and SCA tools should be added individually, to reduce the likelihood of build errors, improve troubleshooting mechanisms, and ensure security continuity is maintained. This will also improve the ability to learn from previous iterations and ensure that teams understand approaches to configuration. While pushing out a timeline to support this incremental approach may be off-putting, it has the effect of prioritizing both the short-term satisfaction of the teams involved and the long-term survival of the strategy.
In addition to rolling out integrations incrementally, the security team should take an incremental approach to rolling out the teams and pipelines with which it integrates. Security Champions programs often leverage a similar strategy. Security champions are members of various development teams who act as liaisons and advisors for their teams regarding application security matters. These programs are successfully developed by introducing a security champion into a few select teams, measuring the successes and shortcomings, adjusting appropriately, and continuing to grow. Security teams should first work with development teams once CI/CD pipelines are in place and a strong relationship with security has been forged. This will serve as a training ground for the new model, in which the pipeline integrations can be rapidly refined before being circulated to other teams in the organization.
In Even security needs a DevOps culture, we talked about applying DevOps principles in security processes, rather than just incorporating security into development processes. The same principle applies with CI/CD pipelines. With the growth of software within security, many security teams should and will use CI/CD pipelines for internal tool development. Security should integrate its tools into the CI/CD pipeline as another way to test its new approaches, experience the benefits and limitations of the integrations directly, and ultimately improve the security of its products.
The integration of security workflows into a CI/CD pipeline is not as trivial as the point-and-click approach many vendors advertise. But the principles above can help guide an effective implementation, which moves an aging approach to application security back into the new digital organization. It’s more important than ever to work with the business through seamless development operations. The new reality demands it, and there is no excuse for ignoring it.
Unless otherwise indicated, throughout this website, “we”, “KPMG”, “us” and “our” refer to the network of independent member firms operating under the KPMG name and affiliated with KPMG International or to one or more of these firms or to KPMG International. KPMG International provides no client services. No member firm has any authority to obligate or bind KPMG International or any other member firm vis-à-vis third parties, nor does KPMG International have any such authority to obligate or bind any member firm.