DevSecOps
SUCCESS
DevSecOps is short for development, security and operations. Developers should simply see DevSecOps as a mantra to make everyone accountable for security with the objective of implementing security decisions and actions at the same scale and speed as development and operations decisions and actions.
​
Introducing the Culture, Automation, Measurement, and Sharing (CAMS) concept for a DevSecOps success. Cyberock believes that you will be successful doing DevSecOps if you are:
-
Changing the culture and breaking down silos between teams and departments.
-
Automating our CI/CD pipeline to effectively scale, establish consistency, and enable confident iteration.
-
Measuring and collecting the right data and reducing false positives.
-
Sharing these data and true positives across multiple functions in order to come together and solve problems.
The key to security automation is the ability to provide accurate, fast and real time, reliable, and continuous results. The bottom line is if you are taking a security scan that generates a gigantic report of security vulnerabilities (including false positives) or bugs that you are going to feed into a Slack alert or any business communication platform and Jira or you are going to fail a build using Jenkins plugins you are just shifting the problem left in the CI/CD pipeline you are not actually failing it because the problem still exists. It's necessary to use SAST and DAST scan activities into our CI/CD pipeline and/or implement a IAST solution which combines both SAST and DAST lightweight capabilities and embeds itself into the application and finds vulnerabilities in the background while a developer writes the code and as you click through the application while performing functional testing and tells developers. However, after an application is released into production RASP provides a continuous visibility in the application as it embeds itself into the application and defends the application wherever it lives from being exploited.
​
In sum, RASP solutions add another layer of security in production and allows you to not only determine if someone is attacking your software but also react to that attack and prevent the attacker from continuing that attack by terminating a session, blocking a user, or simply banning an IP address.
Started Thinking About How to Implement Security into CI/CD
If you haven't yet acquired commercial security scan SAST/DAST or IAST tools, your discussions may revolve around identifying where to start the implementation of security within your pipeline and how issues will be tracked and managed on a centralized platform. In the meantime, you may also be researching for potential open-source tools and IDE plugins that could be used to run quick source code scans and a provide direct feedback to developers.
CI/CD SECURITY
Your next step and challenge would be to identify and select effective, efficient, and reliable open-source tools to implement initially. The different aspects of SAST and DAST within your software development lifecycle.
​
​Static Application Security Testing (SAST)
- White box testing
- Analyze source code to find security vulnerabilities
- Source code required
- Find vulnerabilities early in the SDL process
- Less expensive to fix
- Typically scans only applications
- Can discover run-time and environmental issues
​​
Dynamic Application Security Testing (DAST)
-
Black box testing
-
Behavioral analysis
-
Requires a running application
-
Discovers vulnerabilities later in the SDL
-
More expensive to fix
-
Typically scans only applications
-
Can discover run-time and environmental issues
​
It's crucial to avoid any risk of reputation damage caused by a security breach incident such as the 2017 Equifax data breach which impacted the personal information of approximately 147 million people after failing to observe basic security best practices such as failing to patch a web server in this case. The goal of implementing security checks right from the beginning is the basic starting point in securing your CI/CD pipeline.
Small companies with limited budget could start small. The simple best course of action you may want to consider is implementing open-source code scan solutions to prevent developers from committing cleartext passwords and other sensitive data to your repository. Thus, making sure that your git repository does not have any secret or access keys preconfigure in it.
It's also important to leverage automation to automate scans for each phases of SDLC instead of trying to do it manually. For instance at the IDE, whenever a commit is pushed a lambda function can automatically scan the code looking for any secret keys and cleartext passwords. If an issue is found the commit would be in violation of best security code practices and the commit would be simply blocked. A notification must be sent to the developer saying for example, "The repository has a secret key and plaintext password and is not a best practice. Please modify it and try to make a commit again!" This way you will enforce best security code practice by making sure that your code is more secure and ultimately preventing potential security risks or breaches in the future.
