DevSecOps: Integrating and Maturing a Security Culture
Over the coming weeks, Cybrary will be posting a series of blogs that correspond with the newly released Cybrary course, DevSecOps Fundamentals. This post is the first in a series that covers core principles to assist in the automation of a secure pipeline.
The series will address DevSecOps as a continuously maturing process. DevSecOps is not simply a method of adding tools and automation. The maturity comes from streamlining processes by integrating the Development, Security, and Operations teams to act as a cohesive unit through the lifecycle of the application. The content for the blog was developed from many free resources, including the following:
- DoD Enterprise DevSecOps Reference Design v1.0 [ download ]
- OWASP DevSecOps Maturity Model [ website ]
- NIST Secure Software Development Framework (SSDF) [ draft ]
The blog posts will follow the DevSecOps lifecycle to identify tools, processes, and best practices for creating a streamlined and effective secure code development cycle. The series of blog posts will follow the agenda:
Securing the Development Cycle [current post] What are We Defending?
- Pipeline: Planning and Awareness
- Pipeline: Development
- Pipeline: Delivery
- Pipeline: Deployment
- Pipeline: Operation & Monitor
- Summarize the learned concepts
Please follow the posts and provide feedback or questions to the author using the contact information at the end of the blog.
What is DevSecOps?
DevOps is the relationship between the Development and Operations teams, which promotes a tight integration through collaboration. DevSecOps is the integration of Security into the pipeline of DevOps over the full lifecycle. The integration involves planning, testing, securing the handoff, and monitoring the system. DevSecOps is not merely the implementation of tools to automate testing source code or running webapp scanners. Since DevSecOps cuts across many boundaries of an organization, the target audience includes developers, auditors, Chief Information Security Officers (CISO), and other executives.
What is the Problem?
The culture of the organization must change, which also requires executive leadership to champion the cause and direct division leaders to implement the plan. Security needs to understand how Dev and Ops work to become part of the solution by recommending tools and processes which work in conjunction with the pipeline. Dev and Ops must understand Security’s role as part of the team and assist with integrating the existing collaboration, tools, and processes. Security must also be mindful of the constraints of the Development team along with the restrictive timeline of Agile development. The Security team needs to provide resources with knowledge of development and operations who can speak the language and integrate into the teams.
Why is DevSecOps so Difficult?
How to Integrate Security into DevOps?
The DevOps cycle includes distinct tasks for the Development and Operations teams and identifies the handoff stages from release to delivery. Integrating Security into the DevOps cycle requires the implementation of activities that correlate with the phases of the application lifecycle. The DoD Enterprise DevSecOps Reference Design included a graphic that depicts the actions the Security team can perform to enhance the posture of an application.
DoD Enterprise DevSecOps Reference Design v1.0
Jenkins Pipeline Orchestration
The DevSecOps course implemented a Jenkins pipeline to automate the testing of a Java application and to demonstrate the tools needed during each stage. Each blog post will expand on the activities and tools for a stage and culminate in a simplified but complete pipeline for performing a security review of an application. By the end of the posts, we will have built a Jenkins pipeline:
Stage View Jenkins pipeline automation of Security stages
The automated tools serve two goals. First, Security must evaluate the application at multiple points in the process since each stage can add additional code or software which increases the attack vectors. When the application is built, 3rd party libraries may be added, which could include published or unpublished vulnerabilities. When the application is deployed, the application server, web server, or other infrastructure may introduce additional vulnerabilities based on misconfigurations. Second, no security tool is perfect; therefore, we must implement tools that overlap capabilities to identify as many potential risks as possible. Each stage provides an opportunity to fix risks before they are embedded in the application, which also reduces the costs to repair. Vulnerabilities identified in the development phase can be adjudicated quickly versus vulnerabilities identified in a built application, which then require additional rounds of acceptance and regression testing.
Cybrary offers courses that cut across the entire DevSecOps topic. You can take classes on secure programming, hacker fundamentals, system administration, cloud certifications, and much more. The knowledge will be fundamental to implementing a secure application across the lifecycle of DevSecOps. Signup for Cybrary to learn more about the topic and stay informed of the continuous release of cybersecurity training at Cybrary.
About the author
Dr. Philip Kulp is a Cybrary Fellow and instructor of several courses on the platform. In his current role as a cybersecurity architect and incident responder, he combines his passion for IT and cybersecurity to develop realistic approaches to secure the enterprise. He performs the roles of an independent assessor, incident responder, and secure code reviewer. Philip seeks opportunities to balance his cybersecurity skills between academic, technical, and compliance roles. He holds the CISSP certification and two Offensive Security certifications of OSCP and OSCE. In his educational capacity, Philip serves as a chair, committee member, and mentor for doctoral students in the Ph.D. and D.Sc. programs at Capitol Technology University.