What are the DevSecOps quick wins or low-hanging fruits if you are about to start with the topic of security in software development?
You want to bring your agile development and application security to the next level. Or you have heard the buzzword “DevSecOps” one too many times, so you decided to start implementing it in your company. Yet, you are still asking yourself where to start.
What is DevSecOps
Many development teams are already incorporating DevOps pipelines to work more agile and close to customers’ needs. However, the perks that come with DevOps bear some risks…
The ever-growing pace with which development teams create new features and go through the software development lifecycle leads to security vulnerabilities within the web applications production environments.
Developers can create secure web applications with minimal security issues using the DevSecOps approach and vulnerability management across the development process. Furthermore, by improving this process repeatedly, DevOps teams can eventually achieve continuous security for their web applications.
We hope that you now have a clue about what DevSecOps means. So let’s get started with our six quick wins.
1. Do Dependency Checking
You are probably using libraries in your applications. Your application may be secure, but that does not help if the used dependencies have security risks. So make sure to check them for critical vulnerabilities.
Here are some examples of tools that you can use:
- Python – https://pypi.org/project/safety/
- PHP – https://github.com/sensiolabs/security-checker
2. Do Docker Container Checking
Are you using Docker containers to ship your code as fast as possible? Great! But how about the security of your Docker containers? The same that holds for your libraries is true for your Docker images.
Ensure that you only use trusted base images (such as the official Linux distributions or images of your programming languages) and check that they don’t contain any vulnerabilities.
If you are using a provider to host your built containers, find out whether they may do the container vulnerabilities check for you. This is, for example, the case with the Google Container Registry or Dockerhub (Premium).
3. Don’t Use Root
The default account in most Docker containers is root. Please do not use it.
For security concerns, you wouldn’t do that on your “normal” servers. So why would you do it in the container image?
Create your user as a standard user account and use them:
# Create appuserRUN adduser –disabled-password –gecos ” appuser# Switch to appuserUSER appuser
4. Do Security Code Reviews
No matter how experienced you are, the chances are that your code has some security flaws. An easy way to check your code for security problems is by implementing peer reviews into your processes.
Peer reviews are an excellent tool for code quality. Leverage them to focus on security and prevent logical mistakes that lead to trouble.
So always let your fellow developer look at your code to check it for any security flaws. Even if the reviews result is that you didn’t have any open issues, you and your partner can continuously learn more about secure coding by looking at other people’s work.
Follow these steps as a guide for your code reviews:
- Write your source code
- Submit the code to the repository
- Create a Pull request
- Have it checked out by a colleague
- Use their feedback to improve your code
- Repeat steps 4 and 5 until both you and your partner are satisfied
- Merge the Pull request and deploy your software
5. Always Ask Yourself: What Could Go Wrong?
You may have heard of “Evil User Stories” and “Abuse Cases.” We highly encourage you to add these new issues to your typical “User Stories” or “Bugs.”
If you want to go for the quick win: For every user story or use case that you are planning and implementing, ask yourself: “What could go wrong?” – Is it a missed authentication? Is it a logical error? Is it an overload of your system?
If you think about this during the implementation, you can easily ensure that those cases don’t happen.
6. Create a Responsible Vulnerability Disclosure Policy
Unfortunately, we are all humans and can’t get it 100% right every time. Therefore, we need the support of others.
Creating and managing a bug bounty program is a lot of work. And you may not want people hacking your application all the time (even for a good cause).
By creating a responsible vulnerability disclosure policy, you tell the standard users and researchers how to contact you in case of issues. You invite them to report any vulnerabilities instead of abusing or selling them. Ensure a good layer of security checks in your DevSecOps pipeline before publishing it.
You will be surprised at what people can discover when they have a closer look and how many submissions you get without any advertisement for such a program.
In addition, many researchers have a Google Alert on keywords like “vulnerability disclosure” and may start hacking you as soon as you publish it on your website.
Bonus: Create Your Infrastructure as Code
Six DevSecOps quick wins are not enough for you?
This requires a bit more effort but will help you manage your services.
In addition, you can use the same security processes as for your application code (e.g., code reviews).
Bonus 2: Implement Automated Vulnerability Scanning
Make sure you implement a DevSecOps automated vulnerability scanning to do the heavy lifting for you – doing the black box pentesting part. So, you can focus your time and effort on digging deeper into white box testing and particular vulnerabilities.
Incorporating DevSecOps is the only approach that will lead you to continuous security for your web application in a fast and responsive development environment.
However, implementing it in your entire team will take time and effort, and you might need more information on the matter.
We hope these 6 DevSecOps Quick Wins will help you start your vulnerability management journey and start with a few integrations. You should check out this SecDevOps post or our further resources on Security Best Practices for more information.