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.
Continuous delivery
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 only when they reach the users. 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 and also in short cycles. It’s a good thing that you keep improving your software at regular intervals, but wouldn’t it be better if security was also a part of this? This question lead engineers to think, “Why not make even security a part of continuous delivery?”
In the early days, focus on security came after the application was ready and initial releases were made. But with the number of threats out there today, you can’t afford to wait for so long. Hence, security became an integral part of continuous delivery. And this gave birth to security as code as a new concept.
Components of Security as Code
While security as code is a part of DevSecOps, you can select certain tasks in the development phase that solely focus on the security aspects. Here are 3 main components of security as code that deal with application security:
- Security Testing
- Vulnerability Scanning
- Access Control and Policy Management
Security Testing
Security testing focuses on testing the code to see if there’s an issue that could be a threat to Confidentiality, Integrity, and Availability (CIA triad) of the application. A common misunderstanding is that security testing is done to prevent attacks. But security is more than just preventing attacks. It also includes accidental malfunction, data breaches and much more that wouldn’t include an attacker. For example, a server or a firewall break down or malfunction is a security issue even if it didn’t involve an attacker. Security testing is the process of making sure that the application is safe and protected from any security risks. You can do this by setting up security standards and test if your application meets these standards.
Vulnerability Scanning
Vulnerability scanning unlike security testing focuses more on security weaknesses that an attacker can exploit. Vulnerabilities like SQL Injection, Cross-site scripting, etc., are something that attackers regularly keep looking for in an application. Vulnerability scanning helps you identify well-known vulnerabilities in your application which you can then fix. You can start with running vulnerability scanners at first but after a certain point of time, they will only be of little help. After regular fixes and upgrades, hardly anything will show up on these scans. You should then consider pentesting or bug bounty hunting programs.
Access Control and Policy Management
Applications these days have become complex. There’s a lot of things that happen before one web page can be displayed to the user. This complexity also increases the surface where things can go wrong. With custom requirements and user-specific data, it is very important to set boundaries on what one particular user can do. Access control and policy management are used to set these boundaries within the logic and flow of the application.
For example, a user trying to buy something on an e-commerce website shouldn’t be able to modify the price of the product. The ability to modify the price should be permitted only to admins or owners. Such logics are controlled by access control and policy management.
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.
- Increases application security visibility.
- Makes release cycles shorter.
- Security patches and updates reach the users faster, decreasing the scale of attacks.
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.
Buffer overflow
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 injections
- Cross-site scripting
- Shell injection
SQL injections
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
Cross-site scripting (XSS) is mainly used to hack a web application. 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.
Shell injection
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.
You can get an overall view of your software security and improve it by taking a SAMM approach too. Quoting from OWASP’s SAMM project:
The Software Assurance Maturity Model (SAMM) is an open framework to help organizations formulate and implement a strategy for software security that is tailored to the specific risks facing the organization.
SAMM helps you in understanding where your software security stands currently and help you improve it. You will have to implement multiple iterations to get as close to having a fully-secure software. Fully-secure software is a myth but being close to it would decrease security incidents to almost null.
Security as code: Best practices
Security as code has been around for some time now. Many security veterans after spending a lot of time, suggest the following best practices:
- Understand your security requirement early.
- Plan and design your architecture keeping security in mind.
- Keep yourself updated to the latest security standards and consider implementing them.
- Perform regular security testing and vulnerability scanning.
- Use cryptography
- Take care of broken access control and use the principle of least privileges.
- Perform penetration testing and conduct bug bounty programs.
- Handle errors and logs safely.
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.
Conclusion
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.
