If you have not caught up with the trend of shifting security to the left in software development, you have probably heard of something equivalent: the DevSecOps or SecDevOps practices. It consists of doing as much as possible the security operations (scans, checks, etc.) at the earliest possible stages, and not wait until the end to go through « a validation process ». This is more practical, cost-efficient, scalable, and the most agile-friendly.
In this article, we will go through the basic aspects that one should consider for software-factory security. You could, of course, extend it to include more topics, and you probably should. We are just highlighting the most common ones that we had to cover across our interaction with the customers on a variety of domains.
In the following, I will only mention free software or one with a community edition. There is of course a lot of nice paid alternatives out there, sometimes even shipped with the CI/CD solution (the case of GitLab enterprise for instance), and it is up to you to choose what suits you better.
SAST stands for Static Application Security Testing. This practice consists of detecting anti-patterns that could eventually lead to security issues. Such tools operate at the code level in the same manner as a linter will review your code for typing, formatting, or any compliance rules that we could establish for a coding style standard.
Here are some good practices:
Some tools to consider: Snyk, SonarQube, Bandit for Python
Unless you are reinventing the wheel for every component that you are developing, you are probably using and importing a few external libraries and modules. If it is the case, it is your responsibility to manage these third-party components by:
Busting a myth: « Open-source software cannot be vulnerable or malicious because the supporting community or company will prevent that ». While this could be the case for some active projects, you cannot just assume that, as they could have failed some security checks as well (code, dependencies, etc.). You should at least consider checking if the library has some known CVE or issues.
Some tools to consider: npm audit, Safety for python, Dependabot, snyk
Most deployments need a set of credentials at some point. Whether to interact with a database, object storage, or a third-party API, the tokens or passwords need to be securely managed. This is a very common topic in Cybersecurity, and we will detail the proper patterns in a dedicated article. Here are some insights that you need to consider:
Some tools to consider:
Once your app is ready for deployment, it will require some form of compute service to run it: bare metal, VM, container-based, serverless, etc. Compute security is the foundation of any application security, and is either managed directly by you or delegated to a provider, as part of a Shared Responsibility Model. The process is basically about monitoring and applying the security patches of your OS components, as well as the associated libraries and dependencies.
The patch management strategy will depend naturally on the compute technology and at which level the fix needs to be applied. For the most common case of VM or containers, it is basically about rebuilding and deploying your images. If you have opted for a serverless approach, it is most likely that the provider handles that on your behalf without any downtime to manage.
You need to consider the following:
Some tools to consider: OpenVAS, Clair or Trivy for containers
Now that your app is deployed, you need to check it for security issues while it is running. To achieve that, we need a DAST tool, which stands for Dynamic Application Security Testing. Keep in mind that it is complementary to the SAST check explained above.
A DAST tool operates as a lightweight pentest. It performs the usual checks for security vulnerabilities on runtime while considering your application as a black box and attacking it: port scan, SQL injection, cipher checks, banners detection to run specific exploits and even fuzzing.
You should consider the following:
Some tools to consider: OWASP ZAP, Nikto
It goes without saying, but your software factory security will depend on your CI/CD tooling security. The hardening practices will vary according to your stack. Assuming that you are using Jenkins for instance, you should consider the following:
Now that you have the big picture, we can summarize as follows:
The main takeaway of this approach is that the earlier you fix it, the less it will cost you. It goes for vulnerabilities as well as for any other bug.
You will end up having multiple warnings and many false positives: do not be discouraged by that, since it is part of the process. Progressively, you will be able to add nice and smart filters on all these findings and establish a priority system. A simple one will be probably based on the severity of the finding, the CVSS score, etc. If you choose to go with a more advanced solution, some can even give you an estimation of the effort to fix it.
Just remember to measure and keep track of your progress. Do not rely entirely on automated tools, and support them with an awareness program, so that your team can make sense of all these practices and adopt them.