Security and the drive to transform Security and the drive to transform

The challenges that we’re living through will eventually leave the public consciousness. But its effects on the economy and on business cultures and operations will likely be felt for at least the next decade. Now more than ever, organizations are seeking 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 those efforts to digitize may not last long term, most will — we are looking at an acceleration of the digital phase shift, and software development is going to be at the heart of that transformation.

Developing secure software is more critical than ever, but saying “it’s easier said than done” is a significant understatement. Embedding security into software development is more or less a state of nirvana to most organizations. But why is this idea of ‘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 an assortment of 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 run against the application.

However when these individual teams are centralized, there are a series of 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, through the use of Continuous Integration and Continuous Delivery (CI/CD) pipelines.

CI/CD pipelines enable development teams to centralize development processes without overhauling the organization’s internal structure. And in doing so, CI/CD pipelines provide opportunities for 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 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.

There are challenges an organization may face when trying to integrate security into CI/CD pipelines, which the team has to address themselves by driving home a few key principles. By following these principles, organizations can reduce the friction innate in process modernization and transformation.

All changes come with resistance of some form. By integrating security checks into the CI/CD pipeline, security teams have to change the way they operate. These teams will no longer directly oversee and conduct security tests, but rather 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.”

It’s easy to see the benefits that come with this shift. The security team is able to more efficiently scale its operations and focus its time 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 should continually push a positive mentality around this shift and communicate the importance of the benefits the new structure provides.

It can be tempting to zealously engage in new projects to improve the entire organization. But a more successful approach is breaking 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 aim 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, reducing the likelihood of build errors, improving troubleshooting mechanisms, ensuring security continuity, learn from previous iterations, and understanding 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 incrementally rolling out integrations, the security team should incrementally roll 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 that act as liaisons and advisors for their team 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 with CI/CD pipelines in place and a strong relationship with security. Doing so effectively serves as a training ground for the new model, in which the pipeline integrations can be rapidly refined before being propagated 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 yet another way to trial 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 tout. 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.