A couple of years ago, there were two major teams that worked on getting software built: the development team and the operations team. The development team created the software, and the operations team provided everything that was required to build the software. Because there were two separate teams involved, software development took more time.
DevOps was introduced to make the software development life cycle shorter. While software development organizations breathed a sigh of relief with DevOps making the process smoother, there was another challenge. Implementing security in the software became difficult. And to solve this issue, DevSecOps was introduced.
In this post, I’ll be talking about what DevSecOps, aka “security as code,” is and how it could help your organization.
What does “security as code” mean?
When you’re developing software, you keep the purpose of the software in mind. You design and build the software making sure that it works as expected. While doing this, if you also consider the security of the software, that’s security as code.
As a DevOps engineer, you’ll be working on designing, building, and testing the software. You’ll also work on the operations of software development. Once done, you’ll pass the software to another team that will implement the security of the software.
In the DevSecOps practice, you’ll also take care of security while developing the software. Security as code is implementing the security aspects of the software in the early stage of its development. You’ll find the parts in the code that you can identify as vulnerable ahead of time and add security measures.
If you’re planning to implement security as code, it’s important to understand the principle behind it. The foundation of security as code is continuous delivery. Let’s briefly cover what continuous delivery is.
When you develop new software, your work isn’t done there. Making the software better over time is still your responsibility. You might have to add a new feature to the software depending on the demand. If there are any bugs found in the software, you’ll have to fix them. You might also have to change the configurations to optimize the software.
Any changes you make to the software will be effective when they reach the user. Continuous delivery is the process in which you ensure that the changes made to the software reach the user in a safe and reliable manner.
How does security as code help?
You might be wondering, “Why should I focus so much on security while developing the code when there’s a dedicated team to take care of it?”
Implementing security as code doesn’t mean eliminating security monitoring and protection in production, penetration testing, or ethical hacking teams. Security as code will just add another layer of security along with the contribution of other more security-focused teams and tools.
Implementing DevSecOps has more advantages than just increasing security. Here’s a list of a few benefits:
- You can respond to changes and security needs faster.
- There is better collaboration between teams.
- You can identify vulnerabilities in the code at an early stage and fix them.
- Development cost is reduced due to early identification and fixing of security issues.
- There are opportunities for security automation.
Now that you know what security as code is, let me tell you about some common threats to secure your software from.
Security threats at a code level
There are two major types of threats at the code level that you’ll commonly face:
- Buffer overflow
- Code injection
You should know what the threats are before you can implement a countermeasure. You’ll now learn, in brief, about these two threats.
When you’re writing a program, you’ll be using a lot of variables. When you use a variable, your system will store the variable in a temporary memory called a buffer. Buffer overflow occurs when you try to access data beyond the buffer’s boundaries. Buffer overflow attacks can cause the attacker to crash the system, steal data, or corrupt the data.
You’ll find two types of buffer overflows: stack buffer overflow and heap buffer overflow.
Stack buffer overflow
A stack is a data structure in which you can add and remove elements only from the top. When you use static variables in your program, the program stores these variables in the stack. A stack buffer overflow occurs when a program writes to a memory address that is outside the intended memory of the call stack.
Heap buffer overflow
A heap is a tree-based data structure in which the tree is a complete binary tree. When you use dynamic variables in your program, the program stores these variables in the heap. A heap buffer overflow occurs when memory is allocated to the heap and data is written in this memory without checking the bounds.
Code injection attacks
Code injection is when a hacker exploits a vulnerability in the system by injecting malicious code into the system. These represent several entries on the OWASP Top Ten list, and are some of the more critical vulnerabilities to protect against. There are three main types of code injection attacks:
SQL injection attacks are one of the most common attacks on software that uses an SQL database. You can perform an SQL injection attack by injecting a malicious SQL query into the software. A hacker can use SQL injections to steal data, modify the database, and also destroy the database.
Cross-site scripting (XSS) is mainly used to hack a web server. A hacker can inject malicious HTML or PHP code into the application to exploit any bugs. Hackers use XSS attacks mainly to steal data and modify the content of the website.
This happens when you’re using the shell or a terminal of the system to run certain commands using the input as a parameter. If a hacker gives malicious input, then the terminal will execute the hacker’s code along with the code that you’ve written. Shell injection can cause a whole system crash.
You can find out about more threats here. Now that you know about the attacks that can happen, you should know about some practices to implement security as code.
Implementing security as code
If you’re planning on implementing security as code, this section will give you a heads-up on what to do.
The first thing you should understand is that DevSecOps is a culture, not just using a set of tools or techniques. There’s always resistance to change so you have to take it one step at a time.
You have to define the security policies and start implementing these policies in code. You cannot just expect the development team to change the code based on your current security practices. Bring the DevOps and security teams together and discuss how security as code can be implemented in the current situation. Train the DevOps team on secure coding.
Use automation wherever possible. The main advantage of automation is that it helps you eliminate human errors. This can make a great difference when it comes to implementing security. Choose the automation tool based on your requirements. Some tools are better than others for different purposes. Don’t make the mistake of using the same tool throughout.
Implementing DevSecOps, or security as code, is not a one-step process. You’ll have to implement it at different stages during the software development process. You can find a good checklist for implementing DevSecOps here.
DevSecOps is the upgraded version of DevOps that includes security. Hopefully, you now see how implementing DevSecOps can benefit your organization. If you’re ready to take the next step and planning to switch to DevSecOps, here’s an article that will help you out.
This post was written by Omkar Hiremath. Omkar uses his BE in computer science to share theoretical and demo-based learning on various areas of technology, like ethical hacking, Python, blockchain, and Hadoop.