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.
- First of All: What Is DevSecOps?
- Do Dependency Checking
- Do Docker Container Checking
- Don’t Use Root
- Do Security Code Reviews
- Always Ask Yourself: What Could Go Wrong?
- Create a Responsible Vulnerability Disclosure Policy
- Bonus: Create your Infrastructure as Code
First of all: What is DevSecOps?
Many development teams are already incorporating DevOps pipelines in their workflow 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.
Using the DevSecOps approach and vulnerability management across the development process, developers can create secure web applications with minimal security issues. Furthermore, by improving this process repeatedly, DevOps teams can eventually achieve continuous security for their web applications.
Alright, we hope that you now have a clue of 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 own application may be secure, but that does not really 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 already.
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.
You wouldn’t do that on your “normal” servers for security concerns. So why would you do it in the container image?
Create your own user as a normal 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 to implement peer reviews into your processes.
Peer reviews are a great tool for code quality. Leverage them to focus on security and prevent logical mistakes that can lead to trouble.
So always let the 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 types of issues to your normal “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 make sure 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 to have people hacking your application all the time (even for a good cause).
By creating a responsible vulnerability disclosure policy, you tell the normal users and researchers how to contact you in case of issues. You invite them to report any vulnerabilities to you instead of abusing or selling them. Just make sure that you have a good layer of security checks in your DevSecOps pipeline before publishing it.
You will be surprised, 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?
Here is something that requires a bit more effort but will really help you in managing your services.
In addition, you can use the same security processes as for your application code (e.g., code reviews).
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 some time and effort, and you might need some more information on the matter.
We hope these 6 DevSecOps Quick Wins will help you get started on your vulnerability management journey and start with a few integrations. For more information, you should check out this SecDevOps post or our further resources on Security Best Practices.