What can be checked from the OWASP Top 10 in the context of CI/CD?
Integrating security considerations throughout the software development lifecycle, especially in Continuous Integration/Continuous Deployment (CI/CD) pipelines, is critical to minimising the risks of vulnerabilities and security holes. In doing so, the OWASP Top 10, a list of the ten most common web application security risks, provides valuable insight into potential threats and vulnerabilities.
In this blog post, we will take an in-depth look at the OWASP Top 10 in the context of CI/CD pipelines and analyse which of these security risks can be checked automatically.
A01:2021 Broken Access Control
In this category there are a number of security problems where a sensitive object or resource is not properly protected. To prevent this security problem, the application should check whether the user has permission to access a particular object or resource before granting access. This type of problem cannot be detected by an automated web security tool, as such tools cannot determine whether or not a particular user should have access to a particular resource.
However, there are some exceptions where web application scanners can still detect authentication problems.
This is because if an admin portal is accessed anonymously, such a tool can warn of the problem as it can detect a certain pattern in the URL, such as /admin/. However, it cannot warn if a logged-in user can view resources or objects that they are not allowed to see.
It can be concluded that an automated tool cannot distinguish what a given user is are allowed to access. Therefore, it is not possible for a SAST and DAST tool to automatically detect this type of security problem.
A02:2021 Cryptographic failures
This item on the list can only be checked in very general terms, as sensitive data is not the same for every company.
While some data is considered sensitive for one company, it is not necessarily so for another. Therefore, it is not possible for most security tools to consider all scenarios.
Because of this test results could be flooded with false positives. As mentioned at the beginning of this section, some data can always be tested because there is always data that is considered sensitive for any company. These are cardholder data, national insurance numbers and the like.
Likewise, various technical leaks are easily auditable.
This is the case if the application is also accessible via HTTP instead of HTTPS due to missing redirects, the configuration file .htaccess of the web server is accessible via the browser or various security headers have not been set. These scenarios can be specified automatically very easily.
A03:2021 Injection
Injection vulnerabilities are easy for an automated web application security scanner or web vulnerability scanner to detect. This is because they are clearly identifiable technical vulnerabilities and not flaws based on logic or design. What also makes these vulnerabilities easily identifiable is that they are usually data that the user can manipulate. A scanner can easily test this out.
With Cross Site Scripting (XSS), which now also belongs to the category of injections, there can only be problems with the detection of DOM XSS vulnerabilities. Therefore, before using the scanner, it is worth testing it to see if it meets the desired specifications.
A04:2021 Insecure Design
Insecure Design is a vulnerability based on poor architectural and design decisions that allow attackers to attack the application. This vulnerability cannot be tested automatically in a CI/CD pipeline because it is based on fundamental design problems.
A05:2021 Security Misconfiguration
This is the result of a misconfiguration from a server, a software or framework. Many of these security problems can be identified with an automatic web security scanner.
However, most of them need to be checked manually before they can be confirmed as security problems. This is explained below.
One of these problems that cannot be checked automatically is unnecessary network services. You can identify running network services such as FTP, DNS and SMTP on your web server using a port scanner. In doing so, the scanner reports open ports, but must then be verified by a security expert as to whether the reported network services are needed or not.
Another problem is outdated software.
Web security scanners can warn about outdated or vulnerable software used in a web application. They can also identify the version of the web server, the version of the development framework and even the version of known web applications. However, it is up to the developer how to classify these. Since not every vulnerability that is found actually leads to one in the software.
Other problems can be caused by the security settings of the development framework.
In this type, a tool can automatically point out configuration problems that can ultimately lead to malicious attacks. Warnings are issued when debugging is enabled or when error messages reveal sensitive data.
By default, a web security scanner will launch a brute force attack against login forms to identify weak credentials. However, this is usually limited as it can take a long time depending on the complexity of the credentials. Below is a small graphic to illustrate this.
However, it is easy to see if somewhere, e.g. on an error page, the application’s StackTrace is exposed or if various REST operations, such as DELETE, can be performed without checking.
A06:2021 Vulnerable and Outdated Components
This point is very testable. This is because most tools access a vulnerability database during such scans to see whether any security risks have been discovered for the software and frameworks used. This database is very dynamic and constantly expanding, so automatic SAST scans are essential here. Thus, it is up to the developer to scan the application regularly and keep the versions of the components used up to date.
A07:2021 Identification and Authentication Failures
Also a category in the OWASP Top 10 list that cannot be fully identified automatically through black box testing.
One thing that cannot be fully tested, for example, is the insecure storage of user information. Here, passwords are not hashed, but stored in plain text or only encrypted. It is also possible that an already “broken” hash algorithm is used. This problem cannot be tested by means of an automated tool, as it usually does not know how the user authentication data is stored in the database. Thus, a manual test is necessary. However, some security problems in this category can be detected and tested automatically. These are, for example, session IDs that are disclosed in URLs or the unencrypted transmission of sensitive data such as user names and passwords or hashes that are present in markups.
A08:2021 Software and Data Integrity Failures
Software and Data Integrity Failures refer to the integrity of software and data, often due to a lack of verification and protection mechanisms. Although it is difficult to verify software and data integrity in an automated way, measures can be taken in a CI/CD pipeline to address this vulnerability. This can include implementing code verification procedures, digital signatures for key software components and files, using checksums to verify data integrity, and integrity scans in the pipeline.
A09:2021 Security Logging and Monitoring Failures
This is another vulnerability that cannot be automatically detected because it is virtually impossible to tell whether logs are stored by an application or not. There is always the possibility that logging is taking place on the local file system or on remote servers.
A10:2021 Server Side Request Forgery
Server Side Request Forgery is a vulnerability where an attacker causes the application to execute requests to other servers or services, often on the server’s internal network. Various measures can be taken in a CI/CD pipeline to check for SSRF vulnerabilities. These include automated tests that send requests to untrusted resources and monitor whether unwanted requests are performed. In addition, static code analysis can check source code for suspicious places where SSRF activity might occur. Container scanning tools can also be integrated into the pipeline to look for SSRF vulnerabilities in containers by checking suspicious configurations and libraries used.
Conclusion
Integrating security considerations into Continuous Integration/Continuous Deployment (CI/CD) pipelines is critical to minimising the risks of vulnerabilities and security holes in web applications.
The OWASP Top 10, a list of the most common web application security risks, provides valuable insight into the potential threats and vulnerabilities facing application developers and operators.
In this blog post, we have analysed in detail which of the OWASP Top 10 security risks can be automatically checked in CI/CD pipelines. The results are presented in the following table.
We found that some vulnerabilities, such as injections and XML External Entities (XXE), can be reliably detected by automated web application security scanners. These vulnerabilities are comparatively easy to identify because they are based on technical configuration errors.
Security misconfigurations can be detected in part by automation, but often require manual review, especially with regard to the need for network services and outdated software.
However, there are also security issues, such as Broken Access Control, Cryptographic Failures, Insecure Design and Software and Data Integrity Failures, that cannot be easily checked in an automated way. These vulnerabilities are often rooted in the architecture and design of the application and require manual reviews and careful design decisions.
The category of identification and authentication failures also requires manual checks, as automated tools cannot always determine whether a particular user should have access to certain resources.
In conclusion, the OWASP Top 10 is a valuable resource for security in CI/CD pipelines by providing clear insight into the vulnerabilities that need to be checked. However, a combination of automated testing and manual reviews is required to ensure a comprehensive security strategy. Implementing security awareness and practices at every step of the development cycle is essential to ensure that web applications are optimally protected and risks are minimised.
If you have any questions, suggestions, or criticism on this topic, please feel free to contact me.
You might be interested in the other posts published in the Digital Frontiers blog, announced on our Twitter account.
