Breaking the build in the CI/CD

DevOps life cycle

By: Meera Subbarao
TABLE OF CONTENTS

To stop the train, simply pull the chain Page 3

Building security into the DevOps SDLC Page 4

Out-of-band activities Page 4

In-line activities Page 5

Breaking the build: The relationship between security and quality Page 6

Security team responsibilities Page 6

DevOps team responsibilities Page 6

Development team responsibilities Page 6

What activities can break the build? Page 7

Benefits of breaking the build Page 7

 To stop the train,
simply pull the chain

As a kid, I often traveled by train in India. I always wondered what would happen if I pulled the chain under the
sign that read, To Stop Train, Pull Chain. My parents warned me that it would cost them a fortune to pay the fine
and that Id be taken away by the police. Even though it scared me as a child, I was still tempted by the thrill of
pulling that chain.

Fast forward 25 years, and I find myself pushing my clients to pull a similar, metaphorical chain. The chain in this
case exists in their fast-tracked continuous integration/continuous delivery (CI/CD) pipeline where the procedural
train moves at lightning speed.

Before digging into why pulling the proverbial CI/CD pipeline chain is important, lets first examine some key
software security activities. Well explore activities that take place in-line with the pipeline, in addition to those
performed out-of-band.

Whats the difference between in-line and out-of-band activities, you may ask? Activities that can be completely
automated and run in a CI/CD pipeline without any human intervention are categorized as in-line activities.
Examples include SAST, DAST, and open source management.

Activities that cannot be completely automated are categorized as out-of-band. Examples include architecture
risk analysis, threat modeling, and manual code review.

Most in-line activities can also be performed out-of-band. However, out-of-band activities cant be performed in-
line. As an example, there is currently no way to automate architecture risk analysis or manual code review.

2017 Synopsys, Inc. | www.synopsys.com | a j b r 3

Building security into the DevOps SDLC
Software security activities can be added throughout the software development life cycle (SDLC). The activities
included within this resource are methodology agnostic. They can be applied to standard SDLC methodologies
as well as Waterfall, Agile, or DevOps methodologies.

Its critical to include security engineering into the following pieces of the software development process:

software requirements

architecture

design

coding

testing

validation

measurement
maintenance

The following out-of-band and in-line security activities illustrate how software practitioners can apply security to
the various software artifacts produced during software development. Organizations can execute these specific
security activities to improve both security and quality of the applications they deployregardless of the SDLC
employed within the organization.

Its critical to include security engineering into the following

pieces of the software development process.

Out-of-band activities
Threat modeling is a blueprint that describes your systems attack surface. It does so by identifying major
software components, assets, threat agents, security controls, trust zones, and the corresponding relationships
between objects.

Architecture risk analysis (ARA) identifies technical risks to a business due to technical flaws in a systems
design. The analysis results in specific mitigation and remediation advice for the individual defects. The ARA
process creates threat models which are then used to discover architecture-level flaws in software.

Manual secure code review discovers violations of secure coding standards and best practices by reviewing the
applications source code line-by-line. Code reviews are commonly completed as a mechanism for evaluating
the efficacy of security controls and coding constructs that are implemented to satisfy specific security
requirements. These reviews are considered manual as they are an activity carried out by humans.

2017 Synopsys, Inc. | www.synopsys.com | a j b r 4

Penetration testing involves the review of an application as it is running to identify potential security
vulnerabilities. Penetration tests are generally tool-assisted as a part of the manual security assessment of
an application or system. As part of this exercise, the tester looks to exploit weaknesses in the application or
system to gain access to restricted information and/or functionality. Penetration testing can be performed using
the following approaches:

1. Black box: Testers have no access to or information about the system. They may use information available
in the public domain to build test cases. Various social engineering techniques (e.g., phishing) may also be
used to gain access to the application or environment.

2. Grey box: Testers are provided with a piece of information (e.g., IP addresses, user accounts, etc.) for use
within the testing process.

3. White box: Testers have access to leverage artifacts about the application (e.g., design documents, source
code, API specifications, etc.) during the testing process.

In-line activities
Static application security testing (SAST) is a software security activity consisting of automated source code
reviews. This static analysis technique uses commercial (e.g., Coverity and SecureAssist) and open source
tooling options.

Software composition analysis (SCA) is a process that consists of compiling, tracking, and monitoring the use
of free and open source software (FOSS) by software development teams.

Dynamic application security testing (DAST) is performed during the SDLC testing phase where the application
or system is tested from a black box perspective. DAST is usually a tool-assisted, automated testing process that
identifies common security vulnerabilities.

Insider threat detection identifies dangerous code written by malicious in-house developers or outsourced
resources. Examples of malicious code include:

backdoors

logic bombs

time bombs
nefarious communication channels

obfuscated program logic

dynamic injection code

2017 Synopsys, Inc. | www.synopsys.com | a j b r 5

 Breaking the build:
The relationship between
security and quality

The main goal when breaking the build is to treat security issues with the same level of importance as quality
and business requirements. If quality or security tests fail, the continuous integration server breaks the build and
email notifications are distributed. When the build breaks, the CI/CD pipeline also breaks. Based on the reason
for the broken build, appropriate activities such as ARA, threat modeling, or a manual code review are triggered.

If the build broke due to a critical- or high-risk finding (e.g., identifying SQL injection), the development team can
resolve the issue, check in the code, and start the next integration. However, if the build broke due to changes in
the API (e.g., addition of a password functionality), this may trigger out-of-band activities.

You may be thinking, OK, were ready to break the build, but who is responsible for breaking it and resolving the
issues? Lets find out:

Security team responsibilities

Configure appropriate tools for security and integrate them into the build pipeline.

Define rules on which the build breaks.

Keep a scoreboard, dashboard, or other dynamic record of outstanding security defects.

DevOps team responsibilities

Assist security team in breaking the build.

Notify development teams of broken builds and why specifically the build was broken.

Development team responsibilities

Fix issues when the build breaks.

The three teams work in coordination to make sure the process is well defined, tools are properly configured,
and developers are ready to fix issues when the build breaks. It may take a few weeks to get the process up and
running, and in some cases months to get it right.

2017 Synopsys, Inc. | www.synopsys.com | a j b r 6

What activities can break the build?
All in-line activities can break the build. Out-of-band activities cannot break the build since they are not
automated and are always manual or need a human to carry out the activity. While not every finding or security
issue will break the build, points at which the build should be broken include:

1. Crossing a threshold for critical vulnerabilities.

2. Crossing a threshold for high vulnerabilities.

3. Identifying a specific vulnerability such as SQL injection or cross-site scripting (XSS).

4. Recognizing a zero-day vulnerability (e.g., Struts2 critical issue) using an SCA tool.

5. SAST scan results indicate that one or more source files failed to compile. Thus, significantly reducing the
overall confidence in the completeness and validity of the scan results.

6. SAST and/or DAST tools running out of memory.

While this list isnt exhaustive, the processes it outlines helps to identify code strength. It also helps the
organization to prevent weak or insecure code from remaining undetected until later phases within the CI/CD
pipeline.

Benefits of breaking the build

Development teams are notified immediately in the case of a failure (e.g., SAST/SCA/DAST failures, high
number of findings, or when vulnerabilities like SQL injection or XSS are found).

The security team is alerted on critical and high security issues as soon as they are introduced in the
application.

Can trigger out-of-band activities which are not normally performed.

There is no one-size-fits-all solution to security and quality. No matter the risks that threaten your applications,
just as you break the build when code doesnt compile, or when unit tests fail, its critical to mandate breaking
builds for security issues as well.

So, go ahead and pull the chain to stop the build.

The first step is to configure the rule sets to break builds on critical- and high-risk issues. One way to ensure that
this practice is upheld in your firm is to incentivize teams to break their builds for security issues in addition to
quality issues.

Explore how Synopsys can help build security into the DevOps SDLC.

Learn more

2017 Synopsys, Inc. | www.synopsys.com | a j b r 7

 THE SYNOPSYS DIFFERENCE

Synopsys offers the most comprehensive solution for integrating security and quality
into your SDLC and supply chain. Whether youre well-versed in software security
or just starting out, we provide the tools you need to ensure the integrity of the
applications that power your business. Our holistic approach to software security
combines best-in-breed products, industry-leading experts, and a broad portfolio of
managed and professional services that work together to improve the accuracy of
findings, speed up the delivery of results, and provide solutions for addressing unique
application security challenges. We dont stop when the test is over. Our experts also
provide remediation guidance, program design services, and training that empower
you to build and maintain secure software.
For more information go to www.synopsys.com/software

185 Berry Street, Suite 6500

San Francisco, CA 94107 USA

U.S. Sales: (800) 873-8193

International Sales: +1 (415) 321-5237
Email: software-integrity-sales@synopsys.com

2017 Synopsys, Inc. | www.synopsys.com | a j b r 8