DevSecOps: What Are We Defending?

Over the coming weeks, Cybrary will be posting a series of blogs that correspond with the newly released course, DevSecOps Fundamentals. This post is the second in a series that covers core principles to assist in the automation of a secure pipeline. The series of blog posts will follow the agenda:

1. Securing the Development Cycle [read previous post]
2. What Are We Defending? [current post]
3. Pipeline: Planning and Awareness
4. Pipeline: Development
5. Pipeline: Delivery
6. Pipeline: Deployment
7. Pipeline: Operation & Monitor
8. Summarize the learned concepts

Please follow the posts and provide feedback or questions to the author via LinkedIn.

Overview

In the first post, we provided a basic framework for the discussion and defined how we would be interpreting the idea of DevSecOps. The previous article described the problem cybersecurity professionals face when attempting to integrate into an existing DevOps culture and the technical challenges related to the number of programming languages and architecture, which need to be secured. In the current article, we describe additional concepts required to understand DevSecOps, such as:

• Static Analysis vs. Dynamic Analysis
• 3rd Party Library review
• Supply Chain security
• Security in the full web stack
• The Jenkins security toolchain we will implement

Static Analysis vs. Dynamic Analysis

Static analysis, sometimes referred to as whitebox testing, is performed on the source code before it is compiled. We include bytecode languages such as .Net and Java in the compiled category to make it easier to distinguish the difference between interpreted languages. Interpreted languages such as Python, PHP, and JavaScript are stored in human-readable text. They do not require a compilation before running, but they are still scanned with Static Analysis tools.

More vulnerabilities can be identified with static analysis since there are no security controls in place to block review of the code. Humans can perform static analysis by reviewing the source code, but the process is labor-intensive and becomes nearly impossible as the lines of code increase. Several open-source tools are available such as SpotBugs for Java and Puma Scan for .Net. Static Analysis tools will be discussed in more detail in the Pipeline:Development blog.

Dynamic Analysis, sometimes referred to as blackbox testing, is performed on the running code. If the application is a webapp, the dynamic analysis tool scans for vulnerabilities such as Cross-Site Scripting (XSS), SQL injection, or other types of web-based attacks. The security team needs to leverage both analysis types since the application server, web server configurations, and 3rd party libraries are not available during the static analysis phase. Dynamic Analysis tools will be discussed in further detail in the Pipeline: Delivery blog.

3rd Party Library Review

Third-party libraries are code developed and published by other authors, which are embedded in the custom code created by your developers. The third-party libraries are referenced in the source code and merged into the running application at compilation or runtime, depending on the type of language. Developers include external libraries to reduce the time it takes to create applications or implement mature software, which has been tested by the open-source community. The security problems arise when the libraries are not reviewed for security vulnerabilities.

A vulnerability in a third-party library can introduce the risk into your custom application. Open-source tools such as the OWASP Dependency Check can review open-source libraries and compare the version against the NIST National Vulnerability Database (NVD). Applications that dynamically load third-party libraries such as external references to JavaScript can also introduce vulnerabilities. Vulnerable libraries can be classified into supply chain security since a compromise of the upstream code would introduce the risk to your application.

Security in the Stack

Security auditors must understand the composition of an application before the tools are selected, and a review can be performed. Not only must third-party libraries be reviewed, but each layer within the application can introduce an attack vector. An application can be composed of containers and other layers such as the database, web server, application server, Content Management System (CMS), cloud architecture, and the User Interface (UI).

Each database vendor and version have unique traits that must be secured to avoid data exfiltration of compromise. If your application uses a CMS such as Drupal or Wordpress, the code must be updated, which includes upgrading themes and plugins. Hackers can also manipulate the verbs such as switching between GET, POST, PUT, etc. to identify unexpected results in the processing of a request. Recent compromises of cloud vendor implementations of metadata is also another attack vector which auditors must review. Finally, malicious actors can attack the client-side of an application via JavaScript, HTML5, CSS, and other manipulations.

Jenkins Security Toolchain

In the DevSecOps Fundamentals course, we developed an automated pipeline using Jenkins for the orchestration. The Pipeline portion of Jenkins is used with a custom script to execute the toolchain. The results of the security tools are parsed by the Jenkins plugin, Warnings Next Generation. The image below contains a sample pipeline script that builds the application and deploys it to a Tomcat server.

We use the Jenkins Pipeline functionality to create steps for each security check in the toolchain. The stages create pass/fail criteria to orchestrate the security checks, which can stop the deployment of the code at any point if the threshold for vulnerabilities is exceeded.

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. Visit his author page on Cybrary or contact via LinkedIn.