Vulnerability Management: The 5 steps that benefit projects

Vulnerability Management at MaibornWolff

Hidden danger: When creating software systems, security vulnerabilities can be unconsciously built into the system. This makes it possible for attackers to gain control over the system or to extract data from the system. If these weaknesses are identified as early as possible in the development process, projects clearly benefit:

• If possible vulnerabilities are displayed directly while code is being created, the developers learn to avoid them in the future. This makes the system more secure and saves money by eliminating errors early in the process.
• Complex penetration tests that cannot be carried out frequently do not fit in with agile process models with short delivery cycles. If you rely solely on penetration tests, vulnerabilities may be put into production that can be points of weakness for possible attackers..

MaibornWolff relies on a combination of open-source vulnerability scanners and the vulnerability management system SecObserve for vulnerability management in its development projects. The vulnerability scanners are integrated into the CI/CD pipelines, while SecObserve transparently displays the vulnerabilities found.

No. 1. Avoiding vulnerabilities is the first step of vulnerability management

First and foremost is the avoidance of vulnerabilities. From the very beginning of the project, our development teams make sure to create as few vulnerabilities as possible. This is important, because otherwise the effort for vulnerability management can become very large and hinder the development team in performing its actual tasks.

To this end, we implement various measures right at the start of the project:

Security by Design

Security starts early in the development process. The security requirements must be clearly defined. In order to determine these, we use a combination of protection need analysis, threat modelling and the risks derived from them. The security requirements are anchored in the user stories and the ‘Definition of Done’ and are thus part of the architecture of the system.

Automated patch management

If libraries and Docker base images are not regularly kept up-to-date, outdated versions used can quickly contain known vulnerabilities. We use tools such as the RenovateBot to ensure that the versions are always up-to-date and to minimize the number of messages from the corresponding vulnerability scanners.

Use of Security Champions and trained employees

The Security Champion is a team member who, in addition to his or her role as a developer, ensures that cybersecurity is deeply integrated into the development process.

Many of our developers have also attended our internal training course “Secure Programming” and learned how to avoid many pitfalls in cybersecurity and how to implement secure code.

No 2. Curated list of open-source vulnerability scanners

There is a large number of tools on the market as open-source or commercial software. You can invoke them manually to check for vulnerabilities, but for the most part they can also be automated very well. These tools can be grouped into five groups:

• Software Composition Analysis (SCA): Modern systems are not completely rewritten from scratch, instead many basic functions are used as libraries. This applies not only to the application code, but also to operating system functions and programs in the case of Docker. It is possible that these libraries have known vulnerabilities that can be exploited by attackers. In Software Composition Analysis (SCA), all libraries are checked for known vulnerabilities.
• Static Application Security Testing (SAST): Programmers can unknowingly build vulnerabilities into the code. For example a manually built SQL for performance optimization can quickly result in SQL injections. Cross-site scripting is possible if inputs and outputs in web interfaces are not carefully checked, or sensitive data is only weakly encrypted due to incorrect configuration of the cryptography. Rule-based searches can be used to identify many of these problems. There are tools for all common programming languages and also for Infrastructure as Code.
• Secrets Detection: Secrets such as passwords or API keys can be erroneously checked into the code repository. Examples include secrets that have been hardwired into the code or an accidental commit of a configuration file. If the code repository does not have a very strict restriction on who can access it, far-reaching attack points may arise. Through these, for example, unauthorized persons can directly access databases or interfaces. There are tools that search Git repositories for such secrets over the entire version history.
• Dynamic Application Security Testing (DAST): This is a class of black-box security testing in which the tests are performed by attacking an application (typically web applications or APIs) from the outside. The tests can be passive, just to look for abnormalities, or active attacks on the system.
• Infrastructure Testing: The running infrastructure, such as the configuration of cloud infrastructures or Kubernetes clusters, can also be checked. Both with checks that run inside the infrastructure and checks from outside for vulnerabilities.

From the large amount of available vulnerability scanners, we have compiled a curated list of tools that have proven themselves in our projects:

No 3. Pre-Built actions and templates for CI/CD Pipelines

Integrating vulnerability scanners into a CI/CD pipeline can be tedious. Each tool has to be installed differently and is called with different parameters. To avoid each of our development teams having to solve this task from scratch, we have created a repository with GitLab CI templates and GitHub Actions. These make the process of integrating the vulnerability scanners very easy by providing uniform methods for launching the tools with uniform parameters. The tools are regularly updated in the repositories, so that the latest features and bug fixes are always available.

No 4. Automated import into our vulnerability management system SecObserve

By default, the GitHub Actions and GitLab CI templates are configured to automatically import the results of the vulnerability scans into our vulnerability management system SecObserve. This means that the development team does not have to interpret reports in JSON or other formats, but have access to a modern user interface.

No 5. Transparency, assessment and remediation in the vulnerability management system

In our vulnerability management system SecObserve (click here for the tool in GitHub), the development teams can view and assess the possible vulnerabilities for their projects.

A tool with a good user experience is important. In this way, the development team can efficiently assess the possible vulnerabilities and has to invest little effort in vulnerability management.

With SecObserve, the development team gets an overview of the results of all vulnerability scans for their project. They can easily be filtered and sorted. In the detailed presentation, the possible vulnerabilities are uniformly displayed with a lot of information – regardless of which vulnerability scanner generated them.

Why are we talking about possible vulnerabilities? The vulnerability scanners typically produce a large amount of results, not all of which require remediation. The development team takes three steps to deal with this number of results:

Eliminate unwanted results

Unwanted results can be:

• False positives are results that have been incorrectly reported by the vulnerability scanner. A certain amount of this is unfortunately unavoidable, as scanning requires complex interpretations of the source code, which are not always correctly recognized.
  
• Not affected are results where the interpretation of the scanner is correct, but which cannot be exploited in production. For example: test code or a vulnerability in a library in a function that is not called.
  
• Not security are results that are not security related.

These results can be eliminated by either changing the configuration of the scanner (excluding code or adjusting rule sets) or by adjusting the status of the results in SecObserve using rules or manual assessments.

Decisions of rules or manual assessments remain stable, i.e. if the same result is re-imported during further runs of the pipeline, the decision made before is not changed.

Accepting risks

In the second step, the development team weighs the degree of risk of the remaining results. The protection needs analysis and threat modelling helps to decide whether the risk of a vulnerability can be accepted in the current context. This decision is also documented by a rule or a manual assessment in SecObserve.

Fix vulnerabilities

Now the development team has the list of remaining vulnerabilities that need to be fixed. How this happens depends on the type of vulnerability.

• In the case of vulnerabilities in used libraries or Docker images, the team can either encapsulate the vulnerable function of the component in its own code, meaning the vulnerability can no longer be exploited by attackers. Or the team can check whether it is possible to switch to another library without vulnerabilities.
• In the case of vulnerabilities in your own code, it will always make sense to change the source code accordingly to remove the vulnerability. The results of the scans often provide assistance by providing examples of correct implementation or references with assistance.
• In the case of secrets, it is not enough to remove the secret from the code or configuration file and check a new version into the repository. Since the information is still visible in the previous versions, the passwords or API keys themselves must be changed in the corresponding systems.

At the next scan, the vulnerabilities that have now been fixed will no longer be reported by the vulnerability scanner and will automatically be set to completed in SecObserve.

Summary: How to successfully manage vulnerabilities

With these five steps, our development teams efficiently ensure that their projects do not contain any known vulnerabilities:

• Create as few vulnerabilities as possible
• Working with open-source vulnerability scanners
• Use our repository with GitLab CI templates and GitHub Actions
• Use our vulnerability management system SecObserve
• Efficiently assess and remediate vulnerabilities

By initiating these procedures at the start of each project, the number of vulnerabilities to be dealt with stays small and the effort for vulnerability management always remains at a low level.

---

About the author

LinkedIn: https://www.linkedin.com/in/stefan-fleckenstein-6a456a30/