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 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.
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 repeatedly, 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 of tools that you can use:
Github checks your dependencies and provides you with security alerts for your repositories. Github currently supports the following languages. (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. 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 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. 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
Scan for free now

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 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, 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 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 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 are not enough for you? 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

Incorporating DevSecOps is the only approach that will lead you to continuous security for your web application in a fast and responsive development environment. 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 get started on your DevSecOps journey and start with a few integrations. For more information, you should check out this article or our further resources on Security Best Practices!