Crashtest Security Blog

Six Quick Wins in DevSecOps

Jun 18, 2019 9:53:46 AM / by Janosch Maier

You want to bring your agile development and application security to the next level? You have heard the buzzword "DevSecOps" so many times? You are still asking yourself where to start?
 
We have gathered six quick wins on how you can get started with DevSecOps.
 
adult-bump-cheerful-1270949
 
First of all: What is DevSecOps?
 
Many development teams are already incorporating DevOps in their workflow in order 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 leads to a lack of security within these web applications.
 
By using the DevSecOps approach and testing software from the very beginning, developers can create secure web applications with minimal security flaws. By improving this process over and over again, development teams can eventually achieve Continuous Security for their web applications.
 
Alright - we hope, that you now have a clue of what DevSecOps means.
 
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 your used dependencies are vulnerable. Make sure to check them for vulnerabilities.
 
Here are some examples for tools that you can use:

Github checks your dependencies and provides you with security alerts for your repositories. The following languages are currently supported by Github(Source: https://help.github.com/en/articles/about-security-alerts-for-vulnerable-dependencies)

https://github.com - Java, JavaScript, .NET, Python and Ruby

2. Do Docker Container Checking

You are 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 base images. Make sure 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 check for you. This is for example the case with the Google Container Registry or Dockerhub (Premium).

3. Don't use root

Default account in most docker containers is root. Don't use it. You wouldn't do that on your "normal" servers for security reasons. So why would you do it in the container?
 
Create your own user as a normal user account and use them:

# Create appuser

RUN adduser --disabled-password --gecos '' appuser

# Switch to appuser

USER appuser

4. Do Security Code Reviews

No matter how experienced you are, 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 have a focus on security as well and prevent logical mistakes that can lead to trouble. So always let fellow developer have a 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, both you and your partner can continuously learn more about secure coding by looking at other peoples work.

Follow these steps as a guide for your code reviews:
  1. Write your code
  2. Submit the code to the repository
  3. Create a Pull request
  4. Have it checked out by a colleague
  5. Use their feedback to improve your code
  6. Repeat steps 4 and 5 until both you and your partner are satisfied
  7. Merge the Pull request and deploy your software

5. 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 just 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 are thinking 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 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 the good cause). By creating a responsible vulnerability disclosure policy, you are just telling the normal users and researchers on how to contact you in case of an 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 in place before publishing it. You may be shocked, what people can discover when they have a closer look and how many submits you get without doing any advertisement for such a program. Many researchers just 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 quick wins is not enough for you? Alright, here is something that requires a bit more effort, but will really help you in managing your services. Create your infrastructure as code with tools like terraform.

Through this, you can create secure base resources such as server instances with a good TLS configuration or pre-configured firewalls. You can use the same security processes as for your application code (e.g. code reviews).

Summary

In a fast and responsive development environment, incorporating DevSecOps is the only approach that will lead you to continuous security for your web application. Implementing it in your entire team will take some time and effort and you might need some more information on the matter.

However, we hope these Six Quick Wins will help you getting started on your DevSecOps journey. For more information you should check out this article or our further resources on Security Best Practices!

Topics: VulnerabilityAssessment

Janosch Maier

Written by Janosch Maier

Co-Founder @ Crashtest Security. I write and give workshops regarding Web Security