This is part one of a four-part blog series about DevSecOps.

Technology is at the core of business today. Maintaining the resiliency of critical data, assets, systems, and the network is mission-critical; crucial to meeting business goals. As a result, development operations (DevOps) professionals must continuously improve the overall resilience —along with the security posture — of workloads, software, and applications (Figure 1). To do this at scale and speed requires the integration of a suite of application security tools in the continuous integration/continuous delivery (CI/CD) pipelines that automate posture assessment and provide visibility to help manage security risks.

At Cisco, we learned early on that application security processes were inhibiting our business agility. We knew we had to embrace an Agile and DevOps culture as early adopters to deliver software products based on business demands rapidly and iteratively. Agile DevOps without application security automation leads to a “hurry up and wait” situation, where some processes move quickly only to be bogged down by others. With evolving technologies such as cloud, Docker, Kubernetes, open-source as well as daily and frequent release cycles, it is hard for application security teams to keep up with the threat landscape. In a typical modern application development and deployment technology stack, 80% of the code base is comprised of third-party software. Only 20% is custom code. Most of the security breaches we have seen in recent years were entirely preventable had there been necessary security measures taken, not only for the custom code but also for the third-party software.

We set out to create a DevSecOps culture that empowers the application teams to continuously build and deploy secure applications instead of being gated by a central security function. To do this, we integrated and orchestrated a suite of application security tools within CI/CD pipelines under a program called Continuous Security Buddy (CSB) for CI/CD pipeline edition. It enables the development teams to ramp up their application security program while making application security transparent and friction-free.

We used the following basic principles in the design of the program:

• Co-design and co-develop the security automation solution so it can work for the DevOps teams
• Integrate the DevSecOps workflow and empower the developers by giving them the flexibility to choose their application security tools
• Propagate security compliance requirements and hence eliminate the security friction points between security and development teams that impact development velocity

Co-design and Co-development of the Solution

We initially co-designed and co-developed CSB for CI/CD re-usable automated security capabilities using joint scrum planning with teams from Cisco Webex. To encourage adoption across development teams, we created an innovative, configurable rollout of CSB for CI/CD shared libraries to simplify the process.

Shared libraries are a collection of pipeline code made for Jenkins that can be used by any pipeline to reference any available code quickly. With one line of code in Jenkins, developers can access all the security scans available in the shared library. The shared library framework simplifies the code contribution workflow via the inner-source process and reusable code configuration in the pipeline by any team using Jenkins.

We quickly learned that we needed to provide CI-agnostic solutions for teams that used other CI tools. We offered such a solution using containers that are published in a centralized repository for development teams to access via Docker.

Security Scan Flexibility

Users can choose what type of automated security scans they want to configure and run. For example, a production pipeline may consist of a binary image scan, static code analysis scans, and a way to view a consolidated report of scans. The final step in the automation process is to send the scan results aligned to Security Control Framework (SCF) to a centralized security platform to meet compliance requirements. These features are all available as part of the shared library and the user needs to add configuration parameters to run it. As part of the CI process, security scans are configured and triggered to run whenever there is a code change. Developers can then continuously monitor the scan results for any new security issues.

Automated Compliance Reporting

Using the CSB for CI/CD shared library, teams can view reports generated from each security scan on the Jenkins dashboard and identify any failing security issues. Teams can also send the security results data to a centralized interface to Jira to help in various assessment processes, such as reviews by security architects. A consolidated report is generated (as shown in Figure 2), which shows an overall compliance score that considers which scans were enabled in the job, (e.g., binary scans, static code analysis, and dynamic scans). Developers can then use this report to view any quick fixes to improve the security posture.

Measuring Progress and Success

After initial development with our Webex team, we scaled the CSB CI/CD approach across several business units at Cisco. We measured the agility, reliability, efficiency, quality, and success of the CSB for CI/CD shared library to ensure the system was operating effectively.

With the program now in place for over a year, some of business value we were able to deliver is captured in Figure 3.

Summary and Key Take-Aways

CSB for CI/CD is an automation framework that utilizes both open source and inner source security tools to provide developers with an easy way to run and view security scans. By adopting the CSB for CI/CD framework, organizations can proactively build and release secure software.

The framework, along with models such as inner sourcing, allows for the collaboration, speed, and scale needed in large enterprises where many development teams are using a multitude of technologies. It empowers distributed application teams to secure their applications while providing visibility to centralized governance teams.

We’ll deep dive into some of the critical security features that we enabled, including Software Composition Analysis (SCA), Container Security, Static Application Security Testing (SAST), and Dynamic Application Security Testing (DAST) in the next blog series. We’ll also include strategies being employed to monitor for architecture drift and continuous threat modeling once an application has gone live to further complement our framework for continuous security.

Have you considered similar approaches to those shared in this blog? We’d love to hear from fellow practitioners. Please post your comments below and check out the rest of the series.

To learn more about how Cisco embeds security and trust

into everything we do, visit our Trust Center.