DevOps Engineer at a tech vendor with 10,001+ employees
Real User
Top 20
Sep 25, 2026
My main use case for Sonatype Repository Firewall is scanning the repository versions. For example, if we have a version of Node.js 5.2 that is vulnerable, we scan the repository's code, receive notifications about vulnerability threats, and add violations and vulnerability ratings. If the severity rating is below seven, we upgrade to the latest version of the code. We scan the repositories based on pull requests, and if any vulnerability threats are found, merging the pull requests into the branches is not allowed. The main motive is code scanning, and if the version is vulnerable, it will notify us about the security threat. This process has changed my workflow by allowing us to add configurations inside the YAML. We create and call Sonatype Repository Firewall inside the YAML and add the security quality gate. Once the code is ready, scanning starts, checking for quality gate, vulnerability issues, security gates, and more. We add everything inside the YAML, calling the quality gate of Sonatype Repository Firewall, and once it has been checked, the code review is done based on the latest code, checking for vulnerabilities. If you want to add Sonatype Repository Firewall, you should start with the quality gate inside the YAML, as it is very useful and easier. You can create feature branches towards development and scan the pull requests with respect to Dev. It checks quality gate, severity rating, vulnerability rating, security hotspot rating, and everything, displaying the results on the dashboard.
I wouldn't know about the challenges or difficulties with implementing Sonatype Repository Firewall because it is managed by the IT department, so I really don't know. I just use it with the CI/CD. Sonatype Repository Firewall's best features include timely reporting of vulnerable dependencies in the software we write, which is one reason why my organization chooses it. Sonatype Repository Firewall has helped my team identify vulnerabilities in open-source components by providing us reports, and we look at the reports to know that we have something to update.
The major use case for Sonatype Repository is for open-source libraries, third-party libraries, and scanning. It gives you the vulnerabilities and security vulnerabilities of these third-party libraries. In terms of lifecycle management and integration with CI/CD pipelines, we assess the pipelines with Fortify integrated into part of the pipeline. When you run the pipeline, part of it is the scanning, and you get the vulnerabilities and the issues in this pipeline.
My main use case for Sonatype Repository Firewall is to check dependencies for vulnerabilities, block any download content that poses a risk, and enforce and adhere to security policies in real-time. I check for any suspicious activity and prevent vulnerable and malicious code from entering the build. When application teams create images, I check for vulnerabilities, block critical and vulnerable-level content, and block packages if someone tries to download unauthorized images or engages in suspicious activities using vulnerability intelligence. An example would be when a developer is building a Java-based application with Maven. As they write code and add dependencies, the build tool requests a package from Sonatype Repository Firewall, which is integrated with the proxy repository that connects to the internet to download packages. During this process, whenever a request goes to the Nexus repository, Sonatype Repository Firewall checks the component before downloading it. If any vulnerability is detected, such as one related to Log4j, the policies applied at the firewall level help block the component containing critical severity vulnerabilities. The actions taken include blocking the download, putting the component into quarantine, and informing the developer that it was locked due to a critical vulnerability.
Many companies, including ours, use Nexus Repository due to concerns about malware and critical vulnerabilities. There should be a specific method to prevent malicious packages from entering the internal network, so our company uses Nexus Repository. We usually consider adding the firewall feature on top of the Repository, with the main purpose being to block malicious packages.
Learn what your peers think about Sonatype Repository Firewall. Get advice and tips from experienced pros sharing their opinions. Updated: October 2026.
We use this tool for QA automation and QA quality checking. We check the quality of the code and the calls with SonarQube. If there is any kind of memory leak, it protects against that. When we want to move the code to the next level, we use Sonar Quality Gates. This is part of a QA automation process. We only then promote the code to UAT and then the product once it passes 80% of the threshold that we set for it.
Senior Cyber Security Architect and Engineer at a computer software company with 10,001+ employees
Real User
Mar 18, 2021
With the security concerns around open source, the management and vulnerability scanning, it's relatively new. In today's world more and more people are going through the open source arena and downloading code like Python, GitHub, Maven, and other external repositories. There is no way for anyone to know what our users, especially our data scientists and our developers, are downloading. We deployed Sonatype to give us the ability to see if these codes are vulnerable or not. Our Python users and our developers use Sonatype to download their repositories. Given the confidentiality of our customer, we keep everything on-prem. We have four instances of Sonatype running, two Nexus Repositories and two IQ Servers, and they're both HA. If one goes down, then all the data will be replicated automatically.
Sonatype Repository Firewall ensures secure software supply chains by inspecting open-source components for vulnerabilities and other threats at the point of ingress.
Designed for real-time protection, Sonatype Repository Firewall not only identifies but also controls potentially malicious, vulnerable, or non-compliant components before they reach development teams and CI/CD pipelines. It offers automation for quarantine, blocking workflows, and integrates with repository managers like...
My main use case for Sonatype Repository Firewall is scanning the repository versions. For example, if we have a version of Node.js 5.2 that is vulnerable, we scan the repository's code, receive notifications about vulnerability threats, and add violations and vulnerability ratings. If the severity rating is below seven, we upgrade to the latest version of the code. We scan the repositories based on pull requests, and if any vulnerability threats are found, merging the pull requests into the branches is not allowed. The main motive is code scanning, and if the version is vulnerable, it will notify us about the security threat. This process has changed my workflow by allowing us to add configurations inside the YAML. We create and call Sonatype Repository Firewall inside the YAML and add the security quality gate. Once the code is ready, scanning starts, checking for quality gate, vulnerability issues, security gates, and more. We add everything inside the YAML, calling the quality gate of Sonatype Repository Firewall, and once it has been checked, the code review is done based on the latest code, checking for vulnerabilities. If you want to add Sonatype Repository Firewall, you should start with the quality gate inside the YAML, as it is very useful and easier. You can create feature branches towards development and scan the pull requests with respect to Dev. It checks quality gate, severity rating, vulnerability rating, security hotspot rating, and everything, displaying the results on the dashboard.
I wouldn't know about the challenges or difficulties with implementing Sonatype Repository Firewall because it is managed by the IT department, so I really don't know. I just use it with the CI/CD. Sonatype Repository Firewall's best features include timely reporting of vulnerable dependencies in the software we write, which is one reason why my organization chooses it. Sonatype Repository Firewall has helped my team identify vulnerabilities in open-source components by providing us reports, and we look at the reports to know that we have something to update.
The major use case for Sonatype Repository is for open-source libraries, third-party libraries, and scanning. It gives you the vulnerabilities and security vulnerabilities of these third-party libraries. In terms of lifecycle management and integration with CI/CD pipelines, we assess the pipelines with Fortify integrated into part of the pipeline. When you run the pipeline, part of it is the scanning, and you get the vulnerabilities and the issues in this pipeline.
My main use case for Sonatype Repository Firewall is to check dependencies for vulnerabilities, block any download content that poses a risk, and enforce and adhere to security policies in real-time. I check for any suspicious activity and prevent vulnerable and malicious code from entering the build. When application teams create images, I check for vulnerabilities, block critical and vulnerable-level content, and block packages if someone tries to download unauthorized images or engages in suspicious activities using vulnerability intelligence. An example would be when a developer is building a Java-based application with Maven. As they write code and add dependencies, the build tool requests a package from Sonatype Repository Firewall, which is integrated with the proxy repository that connects to the internet to download packages. During this process, whenever a request goes to the Nexus repository, Sonatype Repository Firewall checks the component before downloading it. If any vulnerability is detected, such as one related to Log4j, the policies applied at the firewall level help block the component containing critical severity vulnerabilities. The actions taken include blocking the download, putting the component into quarantine, and informing the developer that it was locked due to a critical vulnerability.
Many companies, including ours, use Nexus Repository due to concerns about malware and critical vulnerabilities. There should be a specific method to prevent malicious packages from entering the internal network, so our company uses Nexus Repository. We usually consider adding the firewall feature on top of the Repository, with the main purpose being to block malicious packages.
The product helps with vulnerability and security assessment. It also helps with assessment at the configuration level.
We use this tool for QA automation and QA quality checking. We check the quality of the code and the calls with SonarQube. If there is any kind of memory leak, it protects against that. When we want to move the code to the next level, we use Sonar Quality Gates. This is part of a QA automation process. We only then promote the code to UAT and then the product once it passes 80% of the threshold that we set for it.
With the security concerns around open source, the management and vulnerability scanning, it's relatively new. In today's world more and more people are going through the open source arena and downloading code like Python, GitHub, Maven, and other external repositories. There is no way for anyone to know what our users, especially our data scientists and our developers, are downloading. We deployed Sonatype to give us the ability to see if these codes are vulnerable or not. Our Python users and our developers use Sonatype to download their repositories. Given the confidentiality of our customer, we keep everything on-prem. We have four instances of Sonatype running, two Nexus Repositories and two IQ Servers, and they're both HA. If one goes down, then all the data will be replicated automatically.