Are you developing an IT project and want to add extra security layers to it? No problem, since DevSecOps is the development practice you are looking for. In short, thanks to DevSecOps (development, security, and operations), your development team can integrate security initiatives at every stage of the SDLC (the software development lifecycle).
At IntelliSoft, developers adopt the DevSecOps approach for projects requiring extra data security, including EMR (electronic medical records) and eLegal applications. This way, our team can define security vulnerabilities in repositories, run early threat modeling and static code analysis, review design for security, etc.
We created this article to help you understand DevSecOps and when to use it in IT project development. We also gathered the main differences between DevSecOps vs. DevOps so that you can understand what approach your team must adopt for better project outcomes.
Table of Contents
What is DevSecOps vs. DevOps?
Many wonder, “How is DevSecOps different from DevOps?” It’s really the same thing, but the main difference is that DevOps aims to deliver software as reliably, securely, and often as needed, not to mention ensuring that it works consistently in the production process. With DevSecOps, security requirements are simply added, but the overall workflow doesn’t change. How can this be done?
Below, we briefly review the key requirements and challenges on the road to DevSecOps. If you need more information or help, remember that Intellisoft is always here to consult you.
Defining and Understanding DevOps
Before we delve into security issues, let’s briefly discuss DevOps. Closely related to agile development methodologies, DevOps involves creating a culture in which software development and operations are performed together. The common goal is to ensure that software is delivered to users quickly and hassle-free. To do so, DevOps suggests using sustainable automated processes that speed up delivery and provide fast feedback, creating a cycle of continuous improvement.
So far, so good. However, what if, by speeding up the software delivery process, you miss something essential? Unfortunately, this happens quite often with security issues. This is exactly the problem DevSecOps addresses.
DevOps Security
Vulnerabilities pose a serious threat to software. We do not mean only financial consequences and risks for brand image. Vulnerabilities lead to leaks of a huge amount of confidential data – from internal documents to unreleased products and personal customer info, including passwords. Depending on the jurisdiction, leaks of user data can result in severe monetary fines and legal liability.
Development teams often see security as a burden instead of a possible asset. Security audits and reporting slow down the process and prevent new features from being delivered directly to users. This mindset plays into the hands of attackers. Without giving security the proper place in the software development cycle, we risk seeing a new Wannacry and Heartbleed.
Why Do Software Development Companies Need DevSecOps?
IT infrastructures have changed dramatically over the past ten years. Flexible cloud computing platforms, shared storage, and dynamic apps now offer tremendous benefits.
DevOps applications are rapidly evolving in terms of speed, scalability, and functionality. Still, they often lack robust security and compliance. That’s why DevSecOps was introduced into the software development cycle, combining development, administration, and security under one roof.
Hackers are always looking for the best ways to deploy malware and other exploits. Imagine if they could insert malware into an app during the development process. Now imagine it being discovered when thousands of customers already have it. That’s tremendous damage to customers, as well as the company’s reputation.
Security on par with development and administration is a must for any product company. When you integrate DevSecOps and DevOps, every developer and administrator should think about security in the first turn.
Adding Sec to DevSecOps: Security as Code
Those who are new to business might think that shifting security to the left means that you simply need to make your software available for security team testing as part of the CI/CD pipelining. Just in case, CICD is the combined practice of continuous integration and delivery or continuous deployment. Manual security testing certainly has a place in the process. However, by taking the security requirements just at a certain stage at the end of the pipeline, you’re essentially doing the same “throwing software over the wall” and waiting for the report to arrive.
The image shows that security issues are critical at each stage of DevSecOps.
As a result, the recommendations are likely to be ignored because the implementation will take a while, or the whole process will crash and the release will be indefinitely postponed in order to solve the problems and assess the risks. Either way, it creates a disconnect between the security team and everyone else, which makes it difficult to achieve the desired result, meaning the release of valuable yet secure software.
How does the left shift method work in practice? There is no universal solution, but there is a set of tools and techniques that help integrate security into the software development cycle (SDC). Take a closer look at them.
Appoint Safety Experts
A culture of shared responsibility is of utmost importance. However, it isn’t enough to tell developers that they are all responsible for software security. Keeping track of new attack vectors and malware developments is a job that needs a dedicated employee. You can’t expect the same level of expertise from everyone.
By introducing a security expert to your multidisciplinary team to share their knowledge of best practices, you’ll help your employees recognize and support a collaboration culture with security pros.
Consider Security at the Design Stage
For developers to share responsibility for the security of the software project, corresponding issues need to be addressed before the code is written. Security should be reflected in user stories. It should be discussed during backlog review and sprint planning. When thinking about new functionality, take the time to consider the risks it may pose and how they can be mitigated.
STRIDE threat modeling strategy and tools like the OWASP cheat sheet will help stay on the right track. Thinking about security measures at the design stage won’t guarantee that everything necessary is taken into account, but it’s a good start for promoting a DevSecOps culture.
Add Auto-Security Tests to Your Pipeline
Automation is a priority to DevOps. Not only does it speed up tasks and ensure consistency, it also offloads people, freeing up time for more creative tasks. If you want to deliver products to users regularly and frequently, it’s important that your pipelining has automated security tests.
When writing unit tests, as well as automated integration and end-to-end tests, security should be considered on a par with any other functionality. If your team includes security requirements in user stories and threat models during the design phase, it makes sense to add tests covering those features.
Check Dependencies
Software Composition/Component Analysis (SCA) is another type of automated security testing that can be done early in the process. As mentioned above, almost any code base includes libraries and other open-source components that can introduce vulnerabilities.
The SCA tools examine all possible dependencies. This is an excellent example of a task that is more efficiently done by a computer, especially considering how often dependencies are added to a project.
SCA tools can be run automatically within CI/CD pipelines. Some of them are also available as plugins for IDEs, providing feedback literally on the fly. SCA testing, just like static and dynamic testing, analyzes software for known vulnerabilities. Therefore, you need to ensure that the tools you use are regularly updated with new vulnerabilities and cover areas that are relevant to your product and organization. When it comes to finding new vulnerabilities that you may not expect, you cannot do that without human involvement.
Vulnerabilities = Bugs
The DevSecOps approach assumes that the entire team is responsible for the security of the product. Therefore, you shouldn’t separate vulnerabilities from bugs or vice versa. Any vulnerabilities you find should go into the same backlog as other issues and be prioritized equally.
It’s the responsibility of the entire team, not just the security expert, to fix the vulnerabilities. This approach helps expand the team’s knowledge and expertise, as well as the skills learned that can be later applied to other projects.
Enlist the Help of Experts
In addition to the tests your developers wrote, there are various testing tools that can help you be more confident about your code’s quality. Traditional security scanning tools are not good for automated CI/CD pipelines, but tools that are specifically designed for automation and integrate into pipelines exist. They publish the results to a monitoring panel or pass them directly to bug trackers. As with any automated tests, it makes sense to introduce structure to quickly obtain results in different categories.
Static Application Security Testing (SAST) tools perform static code analysis, checking for known vulnerabilities (buffer overflow, SQL injection, etc.). Since static code analysis is performed for source code, it can be run in the early stages of CI/CD pipelines, immediately after a change commit.
The SAST tools are tied to the language. Some of them integrate with the IDE, thus providing a continuous feedback loop during the process of code writing, and the ability to run tests at any time. SAST tools point developers to lines of code that contain vulnerabilities so they can fix them quickly. However, false positives can occur. To prevent SAST results from becoming useless background noise, it’s necessary to turn off some notifications.
Another option is Dynamic Application Security Testing (DAST), which treats the app as a black box and checks it for known vulnerabilities, such as cross-site scripting, command injection, and SQL code insecure server configuration. DAST tools work with the built and deployed software solutions, so they are usually used in the later stages of the CI/CD pipelines.
Keep an Eye on Production
Despite all the measures you put in place at the previous stages of the development cycle, the risk of a hacker finding a weak spot in your system remains. To protect your organization and users, it makes sense to plug in firewalls and monitoring tools. Runtime Application Self Protection (RASP) tools will also provide additional protection and allow you to automatically detect and block suspicious behavior.
Summary
The benefits of DevSecOps are simple: improved automation of the software delivery pipeline eliminates errors, reduces attacks and downtime. For teams that want to integrate security into their DevOps structure, this process can easily be completed using the right DevSecOps tools and processes. Let’s look at a typical DevOps and DevSecOps workflow:
- A developer creates code in the version control system.
- Changes are made to the version control system.
- Another developer retrieves the code from it and performs a static code analysis to identify any security flaws or code quality errors.
- An environment is then created using an IaaS tool such as Chef. The application is deployed and security settings are applied to the system.
Automated testing is then performed on the newly deployed application, including server side, user interface, integration, security, and API tests.
If the application passes these tests, it is deployed to a production environment.
This new production environment is continuously monitored to identify any active security threats to the system.
With a testable development environment, automated testing and continuous integration, organizations can quickly improve code quality, security and compliance.
