Sonatype Lifecycle Reviews

Our primary use case is preventing major security vulnerabilities.

We use it as part of build our pipeline. We have a plugin that gets scanned by Sonatype as the build runs and it scans for all third-party dependencies. We haven't yet gotten to the point where we fail a build, but we make the matrix visible so we know where we need to focus. In the coming months, we plan to actually start failing builds and preventing releases which have certain vulnerabilities, from going into production.

One of the ways it has improved the way our organization functions is that it has created awareness of unlicensed, third-party dependencies and insecure vulnerabilities. That's what it has done at the moment. It's going to have a bigger impact when we start enforcing it on the build pipeline. Then they will be at a point whereby they have to conform to the policy.

There are a number of open-source components that it has highlighted. It means that we have to find a replacement for them. There's a recommendation that's given when it highlights them. So we can remain in the same open-source components, it's just that there has been a patch or an update to them to close off vulnerabilities.

In the context of remediation costs, there is the issue of reputation if you are not releasing secure apps to market. That's one major problem. Secondly, if you know you're releasing insecure applications, you're incurring technical debt because you're going to have to, at some point, mitigate those security vulnerabilities.

It's become a mandatory control now. We just went through a process of defining all the DevOps controls, and one of those controls is to use Nexus IQ. They can't skip that part of their build pipeline. Every code has to be scanned.

There are a number of features that we find valuable. The basic functionality of Sonatype is its scanning feature. Out of that, you get the reporting capability as part of your build and it gives you the statistics as part of the build report.

There's also a feature whereby, in your IDE, you can get immediate feedback as you're developing. That's also quite a handy feature.

In addition, in our Nexus repository - we have Nexus OSS and Nexus Lifecycle linked together - all our third-party dependencies are scanned.

The policy management is quite federated, in a sense, whereby we can assign a policy specific to an application.

The grandfathering mode allows us to add legacy applications which we know we're not going to change or refactor for some time. New developments can be scanned separately and we can obviously resolve those vulnerabilities where there are new applications developed. The grandfathering is a good way to separate what can be factored now, versus long-term technical debt. In most cases, these legacy applications are simply retired, so to refactor them wouldn't make sense. Most of them go through a rewrite cycle or are replaced by something we have purchased.

There's a very interactive view where there's a recommendation, as part of the reporting. You can click on a certain vulnerability and it will give you a recommendation. For example, if you're using something that's not licensed or has a certain license type, it will recommend to you, "You should go onto this license," or, "Go to this version, which covers this vulnerability." There are actual recommendations that are synchronized with the database in the States.

The solution integrates well with our existing DevOps tools. We're using Atlassian and using Bamboo as part of that Atlassian set. Bamboo is our continuous integration tool. There's an out-of-the-box Nexus IQ plugin for Bamboo. It's really simple to configure and it gives you results as you're building. Also, the API is very rich, meaning that we don't necessarily have to get a report from the front end. We can build custom reports through the API.

They have recently released some online training documentation, because we had to a lot of our own learning. If they had a more comprehensive online tutorial base, both for admin and developers, that would help. It would be good if they actually ran through some scenarios, regarding what happens if I do pick up a vulnerability. How do I fork out into the various decisions? If the vulnerability is not of a severe nature, can I just go ahead with it until it becomes severe? This is important because, obviously, business demands certain deliverables to be ready at a certain time. So, some online tutorials around the administration, around developers, on how to use the tool effectively, would be a good idea.

Where we have extended is that we're using third-party Docker containers. So, we're not just using third-party libraries, but we also have third-party-type Docker containers, or containers from Docker Hub, for example. Somebody else has built the Docker image and we're using the Docker image. Scanning of security and vulnerabilities on that image, specifically, would be useful. It would be good, as we're building an image, or as we're running an image, if we could decompile that image and scan it, to look for any vulnerabilities or any areas where there's been a violation of licensing. For example, we could download a WebLogic container, which could be an infringement of licensing. It's things like that which our developers need to be mindful of. They could simply download any container from Docker Hub, without being aware of the licensing violations or the security vulnerabilities.

The stability is very good. It's extremely stable. We haven't had an instance where it's running out of memory or anything else.

We haven't had an instance where we have run into such high volume that we needed to scale. The only change we made was to increase memory, because we started utilizing the API. In terms of redundancy, all the data is sitting in the database. We have backed up the folder structure, and the worst case is we just restore that folder structure onto any server. You could run it in Docker if you wanted to, as well so that is immutable. It's been made to be a lift-and-shift type of product.

We have 100 users actively using it at the moment. They are developers, mostly.

We haven't had an instance where we needed to call tech support. There haven't been issues to the extent that we needed to get hold of tech support. Most of it we deal with in-house. The last issue was probably a year ago, where we ran out of memory and that was a simple config change.

We did not have a previous solution. We brought on Nexus Lifecycle because there has been a heightened, more aggressive stance on security.

The initial setup is pretty straightforward, both the installation and upgrades. We're running it on a Linux environment, so there's not much that we needed to do there. 

Policy management is probably where it gets a bit complex. That's where I referred to the need for some tutorials, some more comprehensive documentation.

The initial deployment took less than an hour. It's very quick. Download it and run the .jar and you're good to go. We do use an Oracle Database, so we did need to set up the database. We just pointed it to one of our Oracle instances.

The implementation strategy was to start enforcing the policies and, eventually, to prevent things. We are implementing it in such a way that the developers will, at the point of development, in their IDE, be faced with these warnings that they are using insecure, third-party dependencies and where they are violating the licenses. That's the strategy, whereby we simply block such releases from getting into production. That's where we aim to get.

For deployment you literally just need one person. For maintenance, we have just two people, and that's for an entire pipeline. They're automation specialists so they provide automation solutions. They also act as application administrators.

We haven't seen ROI as yet, simply because we haven't been harnessing the full potential of the tool. The way I think we will potentially see a return on investment is if we are using any licenses that could be costing us indirectly. We could be looking at certain technical debt which we could be dropping. Those are the aspects we could look at, but we haven't yet maximized the true, full capability.

Our licensing is bundled. We pay a single licensing cost for both Nexus OSS and Nexus Lifecycle together. So I'm not sure what the individual costs would be. We bought both Nexus Repo - we're using Nexus 2.0 and Nexus 3.0 - and Nexus Lifecycle.

There's SonarQube which does static code analysis, but not at the level that Nexus IQ offers it. There is Artifactory, which does do Docker scanning now.

One thing that Nexus IQ has been able to do is to be almost proactive in its integration. You can be in your IDE, you can be in the build pipeline, you can be in the Nexus Repository, and you can get a view of the vulnerabilities. Also you can get recommendations, so you don't necessarily have to waste time in searching the web for a patching solution or an update to fix the vulnerability. It actually gives you recommendations about what you can do to mitigate the problem. That's a distinguishing feature from the other toolsets.

Have a key, a defined goal because, as much as the tool is there, it isn't able to create a goal. The goal is, "We would like to improve the security of our codebase by at least X percent, ensure that 90 percent of our applications, for example, going to market are secure applications." With that goal in place, I would look at purchasing the tool because it would be an immediate implementation of that strategy. We bought the tool with that idea in mind, but nothing clearly defined on a granular policy level. But that's ultimately what makes the difference, to say we are focusing on looking at these types of either licensing or dependencies. The tool is then just automating that process or enabling us to do that. It's taken us about two-and-a-half years to implement a strategy. Whereas, if we had the strategy initially in place, it would have gone much faster.

The governance is centered around security and licensing. Those are the core governance factors around the policy. From a dev SecOps perspective, it's fundamental for governing your third-party dependencies. That's where the enforcement comes in. Once you've defined the policy, it becomes the law, and you can enforce that law. If you are working in a SecOps-type environment then you would sign off on that policy to enforce that.

We haven't used the Success Metrics to its full potential. We understand it revolves around targets that need to be set and how far you are from those success targets, but we haven't used that as yet.

I wouldn't look at it as a root-cause analysis or a monitoring tool. Yes, it does scan for security vulnerabilities and where we've violated licensing, but it's not used as an Elasticsearch, a Splunk-type, or Dynatrace-type of tool. When it comes to troubleshooting and root cause analysis, will we use our Dynatrace and our Elasticsearch to look at the logs.

A lot of the third-party dependencies are open-source dependencies. A lot of them are provided through Apache, etc. We always look at enterprise solutions because of the nature of our business, but where the is an open-source piece of software which we can utilize as part of our enterprise solution then we do. We haven't scoped Nexus IQ to focus on open-source software. Nexus IQ in and of itself is commercial. If we had to use Jenkins or any of the open-source build tools, it would easily integrate with those open-source tools.

Using Nexus Lifecycle, it might end up taking longer to release to market because you may need to refactor. In an industry where these applications have already been developed and now you end up scanning them and you pick up all these issues, you are going to have to refactor them. That means that either new requests must go into a backlog or you fix technical debt, which is what Nexus IQ is going to tell you to do. It might have an adverse impact at first, but the goal is to get to a point where you break even. 

Now we are at a point whereby our apps are being released into production as secure applications. There is the opportunity with new applications, from the onset, to ensure that they are released as secure apps into the market. That doesn't mean that they might be released faster because that could depend on a number of factors. It could depend on your testing cycle, it could depend on your release process, etc.

We haven't had a one-on-one sit-down, or a survey done to really gauge the type of developer engagement. Our level of adoption has been a little inconsistent. Right now, they're getting the visibility of these metrics, but they don't actually have to do anything about it. But once we enforce the policy that their builds and releases will fail, then they will be forced to do something about it. From a SecOps perspective, it enables them to put that application on a risk register and say, "Listen, we need business to focus on fixing this application, making sure it's secure." That's the direction we are currently headed in. Developer productivity could be based on how automated our pipeline is. We are there. We just have to focus on dev and nothing else. This might actually give them that awareness.

We use it as a repository or manager. We store all our software application artifacts. We also use it for the vulnerabilities.

Before, we had open-source Nexus Repository, but with Lifecycle we have Nexus RM and IQ Server as well and we can scan .jars. In addition, we have the plugins for individual developers, which benefits us and the developers when they introduce a new artifact into their applications. It helps them identify what are potential risks and defects. They can resolve them right there and proceed there with their development.

It also brings intelligence to the open-source artifacts, because intelligent servers scan all the vulnerabilities, identify the problems, and then we can ask the individual teams to fix them. That is a plus.

The solution blocks undesirable open-source components from entering our development lifecycle. There are certain .jars which we can block.

In terms of open-source governance, the tool tells us all the threats that are out there in the public sector repositories, threats which, potentially, no one knows. We get to know them and we can use the tool to let other people know which direction to go in.

The solution has improved the time it takes us to release secure apps to market by at least 50 percent. It has also increased developer productivity to some extent because of the plugin which is included for the IDE. It gives a report of the vulnerabilities. It does save time in figuring out the right open-source versions that we need to use. It has helped improve the productivity of the developers by about ten percent.

The way we can define policies and apply those policies selectively across the different applications is valuable. We can define a separate policy for public-facing applications and a separate policy for the internal applications. That is cool.

Since we have public-facing applications, they are more vulnerable, because anyone from anywhere can access them: for example, Excel and Java scripting. We can detect if we potentially have any .jar open-source product that can become vulnerable. We can define stricter policies for the public-facing applications, versus internal where we are protected by the firewall. We already have a more secure way of accessing those internal applications, so we can limit the strictness of the internal policies a little bit. We can relax some of the rules there defining the different levels, from a security perspective. That is useful.

In addition, we like the way, when the product has found a vulnerability, that it also recommends the version in which that particular vulnerability was fixed. It generates a report with all the different types of vulnerabilities that were found. We can then go to individual vulnerabilities and look into the historical information: When, and in what version of the .jar, it was introduced, when it was fixed, and what the usage in the market is for that particular open-source component. That is very useful information to us.

The solution's data quality shows in the way that it recommends the correct artifact that we should use and the different versions that are available. Based on that data we can make better decisions.

It also integrates well with the IDEs. Instead of discovering a problem during deployment, we can identify the problem right at the development phase. That is a cool feature of Lifecycle. We use Bamboo for our builds and the Nexus IQ plugin is compatible with Bamboo. We can scan the vulnerabilities at build time.

It doesn't provide real-time notifications from the scans. We have to re-scan every time, whenever a build happens.

Also, since Nexus Repository just keeps on adding the .jar artifacts whenever there is a build, whenever an application is going up, there is always a space issue on the server. That is one of the things that we are looking for Nexus to notify us about: if it is running out of space.

It is stable as of now, the version we are using. We hope that it continues to work as we expect.

We haven't actually explored scalability. But in terms of scalability, if there is anything that we need to add, like CPU, memory, or any extra RAM, that can be added dynamically. But we are not sure if Nexus would need downtime for things like that.

Technical support has been really prompt.

We used the open-source version before moving to the licensed version of Sonatype.

The initial setup was okay. It was pretty straightforward. We had some hiccups in the migration itself when we migrated from open-source to licensed Nexus. At that time we faced some issues with the configuration and we had that resolved. But the deployment took only an hour.

Because we had an existing, open-source Nexus RM, we had to migrate it to the new, licensed Nexus Pro version. So we had to coordinate with other teams, come up with a plan, and then execute accordingly.

We have only been using the licensed version for six months. But long-term, we definitely see it saving time and that will be our long-term return on investment.

Pricing is comparable with some of the other products. We are happy with the pricing.

We didn't look at any other options. We have been using Nexus for years. We had some initial sessions with them, we did a PoC and we liked the product. We went ahead with it.

Their support is good. They help with understanding the environment. They helped us with the initial PoC work. Their product is configurable. We can customize the policies. We had some hiccups, but it was pretty self-explanatory once we understood all the different parts. It was easy to set up and get going. From an implementation perspective, it's not a complex setup, which is a good thing.

We have ten people using the solution, which includes developers, some of our managers, and architects. For deployment and maintenance of Nexus, we need just one person, a developer.

We have pretty much scanned all of our applications. We have around 30-plus Java applications. Based on the current set of applications and the number of users who are using this product, there are no plans to increase usage at this time. 

We have it implemented and integrated into our CI/CD pipeline, for when we do builds. Every time we do a build, Jenkins reaches out and kicks off a scan from the IQ Server.

We use it to automate open source governance and minimize risk. All of our third-party libraries, everything, comes through our Nexus, which is what the IQ Server and Jenkins are hooked into. Everything being developed for our big application comes through that tool.

We have Nexus Firewall on, but it's only on for the highest level of vulnerabilities. We have the firewall sitting in front to make sure we don't let anything real bad into the system.

Our environment is your standard, three-tiered environment. We have the developers develop in their Dev and Test environments, and as the code moves through each environment — Test and a QA environment — it goes through a build process. We build each time we deploy.

We're addressing anything that is a nine and above. If it's a 10, we don't let it into our system; the firewall server stops it. If we have nines we'll let it in, but I'll tag the developers and they'll have to do a little triage to figure out if the problem that is being reported is something we utilize in our system — if it's something that affects us — and if it's not, we flag it as such and let it go. We either waive it or I'll acknowledge it depending on how much it's used throughout the system and how many different components are being built with that bad library.

It really hasn't an improved way we function, but it's helped us to get the developers to start thinking about the security posture that we want to have, going forward, with applications that we develop in-house. It's helping to educate the developers who don't think about these things when they're throwing code together.

It has also brought open source intelligence and policy enforcement across our software development life cycle. That's what we're moving to. We're not 100 percent there, but that's the goal. It's getting the developers to actually think about the third-party libraries they're pulling into the system and to think of them in a different light, in terms of the security aspects of them. I was a developer for 20 years before I got into security. As a developer, you don't always think about the security aspect of things. You're looking for a library that does X, Y, and Z. Lifecycle helps keep that security issue front and center, because as you're bringing it into the system, or as you're doing the build, it's breaking a build or it's doing other things.

It's helping to block undesirable open source components from entering our development lifecycle at least once or twice with every round of releases or library upgrades.

It has also improved the time that it takes to release secure apps to market, although we haven't put a number on that. 

And we have seen an increase in developer productivity because the tool allows them to go out and look for the libraries that aren't affected, or that don't have all the negatives in them. The component piece and the IQ Server aspect has saved time. Without this solution in place, the developers wouldn't care. If this tool wasn't in their face, making them care, a lot would slip by. This is our way to make sure we're watching the gate. Without it, we would be in a much worse spot in terms of exposure, risk, and data exfiltration.

The component piece, where you can analyze the component, is the most valuable. You can pull the component up and you can look at what versions are bad, what versions are clean, and what versions haven't been reported on yet. You can make decisions based off of that, in terms of where you want to go. I like that it puts all that information right there in a window for you.

The default policies are a good start. Within our environment, I tweaked each level to have its own policy, just because of the control it gives us. It provides us with the flexibility we need.

The data quality is pretty good. I have not had any major problems. It helps us solve problems faster.

It integrates well with the existing DevOps tools. We plugged it right in. It was an "after-the-fact" thing that we added into our pipeline and it integrated quite easily. We use Jenkins and it was a nice fit with that. We don't have it creating tickets yet, so we don't have it integrated with a ticketing system, but it is integrated with our Jenkins platform.

One thing that it is lacking, one thing I don't like, is that when you label something or add a status to it, you do it as an overall function, but you can't go back and isolate a library that you want to call out individually and remove a status from it. It's still lacking some functionality-type things for controlling labels and statuses. I'd like to be able to apply it across all of my apps, but then turn it off for one, and I can't do that. I have to go to all 100 apps and do it individually in order to get something on each one, and I don't like that. I should be able to add it as a group and remove it as a single.

Everything else has been really good.

I have been using Sonatype Nexus Lifecycle for a year and a half, going on two years.

The stability is good. There have been no problems that I'm aware of.

It's handling a lot of code but if we wanted to roll out more servers and do more build outs, I wouldn't think that it would involve much more than just adding a few servers. So the scalability should be good.

It is being fully utilized in our build process — where our applications are built and deployed. Where we're lacking use is getting the developers to get it plugged into their Eclipse environments and actually using it on a more regular basis. That's where the struggle has been. That's not the tool, that's more an issue with our developer management side. The adoption is just not happening at the pace it should, because of a whole multitude of other things that are going on right now in our company.

The only other thing we might eventually want to do is get it hooked into a ticketing system where it could create tickets if there are libraries that are bad. Outside of that, it's pretty much integrated into our pipeline as far as we're going to integrate it.

Their tech support is pretty good. I only know of one or two instances where the gentleman in our company who does the upgrades had a question, and they were answered and resolved quite quickly.

We did not have a previous solution.

As I was moving into my security role, the pipeline team was already looking at something and it played nice with Nexus. It was an extra add-on piece or something like that. They were the ones who actually introduced it. I liked it and pushed it along.

The initial setup was straightforward and easy. I didn't set it up but I know there weren't any problems. It took less than a day and it took one person to deploy it. We had one person, at that time, setting up the servers. 

Sonatype came in and did a little demo for us and, while they were here, we got the information set up. It was really easy. We didn't have any major issues that I'm aware of.

In terms of maintenance, we just went through a library upgrade and that was done by one person. It took about a day. We have one person who knows the administrative aspect of it at our company. He works on the pipeline team. I'm on the security aspects and the security policies.

Overall, we have over 50 people using it across our organization. They are developers, architects, managers, and in security.

I'm not sure it's saving us anything. I don't have a way to gauge that as far as return on investment goes.

The return on investment for us is that we have the process in place that has our security aspects tied into it. That's more the type of return on investment we were looking for, and it is doing that. We're still in the early stages.

I'm not familiar with the pricing in detail, but I believe it was pretty reasonably priced, compared to the market.

The biggest thing we've learned from using it is that, from a development point of view, we just never realized what types of badness are in those third-party libraries that we pull in and use. It has been an eye-opener as to just how bad they can be.

As far as Lifecycle's integration into developer tooling like IDEs, Git Repos, etc., I don't set that up. But I have not heard of any problems from our guys, from the team that set that stuff up.

I like the tool overall and would rate it at about nine out of 10. There are a few UI-type things that I don't like, that I would like to work a different way. But overall, the tool is good.

We use Fortify Static Code Analyzer and Sonatype in conjunction with Azure DevOps to view all code processes, from scheduling to deployment in production. This is typically included in the build. Therefore, when a colleague performs a build, all scans are automatically done, and they can see the results through the Fortify and Sonatype web portals.

Fortify Static Code Analyzer enables developers to identify and fix broken references within the code. We sought to understand how to write secure code by design.

Finding vulnerabilities using Fortify SAST is not difficult.

Fortify SAST helps our remediation of potential vulnerabilities with accurate and reliable results. While this practice does not allow our developers to build secure code from the outset, as they are currently notified of issues only after the initial build, it does facilitate the creation of secure code before deployment to the customer environment and production.

Fortify SAST has been instrumental in our growth. As a result, I now have a team that consistently writes more secure code without relying on scans. By addressing the same issues repeatedly, we learn to write code correctly the first time, fostering a culture of knowledge sharing. This is facilitated by our weekly meetings where the team discusses key issues and collaborates on solutions.

I can use the dashboard and portal to see our compliance in real-time and address any compliance issues before they become a problem.

The Fortify SAST portal helps me identify vulnerabilities and weaknesses to reduce our risk exposure.

Real-time feedback isn't necessary for us because we receive scan results once a week or on demand. However, the feedback has been incredibly valuable. I can perform a scan and immediately see our current situation. This allows me to quickly assess if our coding practices are effective or if we need to stop and address any issues before they become bigger problems.

Fortify SAST has helped free up around 20 percent of our employees' time to work on other projects.

Fortify SAST's ability to identify vulnerabilities early in the development lifecycle has helped us save significant costs equalling around 40 percent as well as time, as it allows us to catch issues before they reach production. Before using Fortify SAST, we could only identify problems manually, which often resulted in code being deployed with vulnerabilities.

Integrating Fortify SAST is simple and takes around two hours.

The reference provided for each issue is extremely helpful. It allows our team to understand the rationale behind resolving the issue and the specific type of security problem we are facing. This information is crucial for improving our security skills and coding practices. The ability to review and approve each scan before deploying to production is vital. This ensures that our product is free of bugs and complies with our security policies.

The price can be improved.

I have been using Fortify Static Code Analyzer for two years.

I would rate the stability of Fortify SAST ten out of ten.

Fortify SAST perfectly fits our organization's size.

The technical support is good.

Positive

The initial deployment is straightforward. The integration is part of our DevSecOps process and it is completely transparent.

Whether or not the Fortify SAST deployment is done separately will affect its complexity.

The deployment takes about one week and involves ten people.

Although I am not responsible for the budget, Fortify SAST is expensive.

I would rate Fortify Static Code Analyzer a nine out of ten.

Currently, we don't utilize Secure Center. Instead, we have a dedicated server that collects scan data. Fortify scans are conducted on the server hosting DevOps, which then transmits the results to the Fortify server. Due to our organization's size, Secure Center implementation is not currently necessary.

Organizations that are still relying on manual methods to identify vulnerabilities should consider transitioning to SAST for improved efficiency and professionalism.

We have Fortify SAST deployed in one department and we have 14 users.

Fortify SAST's reliance on Java necessitates maintenance due to our predominant use of Microsoft technologies.

I recommend implementing Fortify SAST for enhanced security, as a SAST solution is crucial to ensuring comprehensive security.

Our primary use case is for the SAS testing. This is the dynamic composition analysis that we need to do. In our apps, we do a lot of bespoke development and use a lot of third-party components. Therefore, it is critical to know what number is embedded within the third-party components that we may not directly be responsible for. The main use case is for scanning and ensuring that the deployments that we are adding to our servers is as secure as we can make it.

We use it for scanning alone. That is our way of mitigating risk.

We just upgraded to the latest version.

We have increased the digital footprint of our company over the last few, extensively. We have extensive open source development happening which depend on open source components. Using the scanning with Nexus IQ, a lower count of false positives has helped us roll out our security policies across the development cycle and ensure that our deployments to production are as secure as possible. This helps us avoid critical vulnerabilities being exposed onsite. It saves us time in any remediation activities that we may had after deployment, because if we had discovered security issues after the application was completely developed and deployed, it would be more difficult to go back and make changes or put it back into a cycle. Then, we would have to shift to multiple outcomes due to business expectations, member expectations, and our client expectations. Bringing it back into the development cycle would take a lot of time. Attaching it to the development cycle and by integrating Nexus IQ into our plans, we have a policy that will not allow vulnerable artifacts to be deployed to production. This forces it to be handled during the development cycle.

The solution has increased developer productivity when remediating issues, as the issues are clearly laid out. We are saving five to 10 percent in developer productivity. 

This solution integrates well with our existing DevOps tools. We use it in our Jenkins build pipeline. If the Nexus IQ scan fails, then it produces an error that fails the build. When a developer builds on their machine, as well, it flags issues and lets them know which component has a problem.

This solution brought open source intelligence and policy enforcement across our SDLC (software development lifecycle). The enforcement is simply because the build pipelines use Nexus IQ, then it fails when Nexus IQ has an error and identifies a component with multiple security issues because it breaks the release pipeline. The enforcement is there because you can't release anything without going through that pipeline.

The scanning is fantastic. 

The dashboard is usable and gives us clear visibility into what is happening. It also has a very cool feature, which allows us to see the clean version available to be downloaded. Therefore, it is very easy to go and trace which version of the component does not have any issues. The dashboard can be practical, as well. It can wave a particular version of a Java file or component. It can even grandfather certain components, because in a real world scenarios we cannot always take the time to go and update something because it's not backward compatible. Having these features make it a lot easier to use and more practical. It allows us to apply the security, without having an all or nothing approach.

The application's onboarding and policy grandfathering features are very easy to use. Most developers who I have given access have picked it up easily. The documentation is fantastic. I've never had a reason to contact support or asked a question, as most of the answers are available.

It provides all up-to-date data information on the vulnerable issues for the various components that are available. I am able to see that various versions of the application are clear. Sometimes, there is a direct reference , so we can see what the issue is and what are the workarounds, if any, that there are available. It will even suggest certain steps which could be taken to remediate the issue. This helps streamline all the information available instead of us going to multiple sources and having to correlate information. Everything is easily available in a streamline manner. It is easy to access, review, make decisions, and proceed with fixes.

We use Griddle a lot for integrating into our local builds with the IDE, which is another built system. There is not a lot of support for it nor published modules that can be readily used. So, we had to create our own. No Griddle plugins have been released.

One of the challenges is getting the policy correct. You need to understand when to grandfather components, then come back and do it. Currently, there's no feature in Nexus IQ which says when you grandfather a component, or behave a component. There's no feature to remind me again in two months' time, for example. I had to access a grandfather competent today because I couldn't afford to fix it because of different constraints. I might grandfather it for now, or I might leave it for now, but if there was an option to remind me in two months, or unwaive it in two months' time, that would make it seamless. That way I wouldn't have to remember that there's something to be done. It would automatically start breaking bills and automatically someone will look at it.

I haven't had any issues with it crashing. It is very stable. However, when we use it in real-time builds (or very frequent builds), there is sometimes a bit of lag between getting results back by 10 to 30 seconds. Other than that, we haven't had any issues.

We haven't scaled it because we just had this one server running. We have not had a reason to scale it as of yet.

We have 10 people who can use it, and they are developers in DevOps.

We started off using Nexus IQ very sporadically on an ad hoc basis. Now, we have moved into putting it into some of our pipelines, especially for applications that are in the forefront, e.g., digital footprint applications. There is now a high interest to make this mandatory for all data points. We are definitely looking at an increasing usage.

The technical support is fantastic. The few times when we have asked for help, their answers were immediate and to the point. 

Nexus was our first implementation.

The setup was very easy. The instructions were very clear and the install was easy. There was almost no need for us to contact support or get anyone to handhold us during the installation and set up. There is more than enough documentation which covers what the policies are and how you implement them, etc. We didn't need a consultant to come in and implement it. We could do it ourselves.

The deployment didn't take very long. The deployment was finished in days because we had prepped the environment. What took longer was including using the tool in different projects.

We started off with ad hoc scanning, then moved toward a more automated scanning. Since there are there are multiple different types of applications and pipelines. We started off using Nexus as a standalone ad hoc service where people could use it just to launch the application, as required. Then, when they started seeing the value, they started embedding it into their pipelines.

One of our developers can install this solution. Anyone from DevOps can install and maintain it. We don't have a delegated person for it.

We have seen ROI.

Nexus has improved the time it takes us to release secure apps to market by saving us weeks of rework.

We evaluated different Black Duck and WhiteSource, but chose Nexus because we felt it was the best product offered.

In early 2017, Black Duck had an approach of uploading everything all at one time, then coming back later to see the report, which Nexus IQ didn't. Also, with the price points, there were distinct differences between Black Duck and Nexus IQ.

We use it for checking our open source libraries for Java and .NET. I think they also have Python and R that some of my colleagues are using. And on the other side, of course, we also have the proxy to only download the open source libraries for our internet software development that are free of vulnerabilities and security issues.

It's deployed on-prem. We have internal servers.

Before we had Nexus Lifecycle, our software developers needed to clear each download from open source libraries. That meant they needed to scan the library on a separate PC, and then they would integrate it into their solutions, but it would be local and not available for the other developers. Now, we have an automatic process for downloading open source libraries, and this has removed a huge effort for all of our software developers. That is the big advantage, that we have an automated software development pipeline, which is something we did not have before. All of our developers are happy to have the solution.

Another benefit is connected to the fact that we also have applications we host for external users and those users can obtain a very good report about which external, open source libraries we are using, and their security status. 

We get email notifications if a certain library has a security issue, like Log4j. We are informed very early and we can check into it and act on it. This is the most valuable feature.

Also, the integrations into developer tooling are quite nice. I have the integration for Eclipse and for Visual Studio. Colleagues are using the Javascript IDE from JetBrains called WebStorm and there is an integration for that from Nexus Lifecycle as well. I have not heard about anything that is not working. It's also quite easy to integrate it. You just need to set up a project or an app and then you just make the connection in all the tools you're using.

We have also set up certain organizations for our company, within the Nexus tool, such as groups or departments. Within these groups, we have the different applications they're working with. This is a structure that Sonatype recommended we implement.

We got a lot of annotations for certain libraries when it comes to Java, but my feeling, and the feeling of a colleague as well, is that we don't get as many for critical libraries when it comes to .NET, as if most of them are really fine. It's true that we have more Java applications than .NET, but the number of our applications in the .NET area will increase. Again, it's just an impression, but it seems that the annotations for .NET are not the same as for Java. It would be good if Sonatype would check the status of annotations for .NET packages.

Again, I note that we are just starting to use an open source library from NuGet for the .NET area, while we have been using it for Java for several years and we are using more packages. For .NET, it's evolving. But my impression is that annotations are more focused on Java, and that in .NET we just do not see as many security issues as in Java. It could be fine, but maybe Sopatype started with Java and then expanded the portfolio to .NET and to other languages. This is something which could be further checked.

It could also be the fact that we have had Java applications for around 20 years, using open source libraries. When you go to the newer versions, you need to check and test. Whereas the .NET applications are evolving and are using open source libraries, and the .NET side is really new for our organization.

I have been using Sonatype Nexus Lifecycle for around one year.

The stability is fine. I have not struggled with it. The solution is working, it's available. But this is something I can't tell you much about it because the server infrastructure and installation are done by our infrastructure team. I'm not sure if they are struggling with availability of the services.

The scalability, currently, is fine, because the performance is fine. It was important to have a structure at the beginning, a way to set up different departments and groups. Now, if we have a new group that will use IQ Server or Nexus Lifecycle, we can just add it and it will be managed by the department. That makes it really good and scalable.

Nexus was a pilot, where some of my colleagues were using it but now it has spread to our whole organization and more colleagues are using it.

An evaluation of Sonatype's technical support is more a question for our infrastructure team.

We did have some workshops with Sonatype about using Nexus Lifecycle and IQ Server, and they were quite nice. They made presentations and we could ask our questions. There is also the offer to have workshops about new topics, but I can't say much about the really technical questions.

However, from my point of view, the communication with Sonatype is really good. They take care of our requests and issues and answer them.

This is the first solution we're using. We had a Nexus repository for several years, and we added Nexus Lifecycle on top in the last one to two years. Before, we would just manually download libraries and clear them by checking the download status. It was a manual task and now it's automated.

I wasn't involved in the server installation. From my point of view, the deployment was quite easy. The servers were set up—a test instance and a production instance. In the test instance, we can play around and see if everything is working.

The IDE integration was quite easy because you just have to download the plugins and then set up the URL and the user and password. With Jenkins, we had to play around a little bit, but it was not that tricky. The integration is really nice because the plugins work quite well.

Because we have only had Lifecycle in production for around one year, it's too early to know if it has improved the time it takes us to release secure apps to market.

But it has definitely increased developer productivity. If you manually download a package, you're not sure if it is the right package because you cannot test it. But now, we can automatically download packages. It's much more effective and more productive for each software developer using it. I would estimate we have seen a 20 percent increase in productivity.

It's also helping our security because that is an aspect we did not check before. That is new for us and very valuable.

We have internal help pages for new software developers with explanations about how they can get access to Nexus Lifecycle and how they can set up new organizations, new applications, and how the IDE integration is done.

We use Nexus as a local repository of both JavaScript and Java components, and we're starting to look at Python. We also connected up to the Nexus Firewall, so that new components that are proxied are looked at to see if they have malicious components or if they are components without vulnerabilities. We're able to establish policies about whether we want to allow those or quarantine them. 

Our main use case for IQ Server is to scan software builds for components with existing vulnerabilities and malicious components. We're working to drive down our technical debt due to components with known issues, and it's been helpful. We're still expanding the program to different software languages. We started with Java and then extended the JavaScript. We want to extend to Python, but we're not quite there yet. We don't have too many Python users, so that's less of a priority.

It's been pretty good. I'm the one who has to un-quarantine things, but the false-positive rate is not too bad, or else I'd be doing that all day. From that point of view it's been good.

The solution enables us to manage and secure the component part of our software supply chain. That is done between the policies, their data, and configuring. You have to make sure everybody's actually pointing to the repo. We started talking about blocking public repos from within the networks, so that would force people to go through the solution, but we haven't quite gotten there yet. However, we have definitely have a lot of people going through the repo. We can see how many components are cached and how many are quarantined. We have definitely had 1,000 or more components quarantined during our use of the product. That's all technical debt we would have accrued if we hadn't been using it.

We really like the Nexus Firewall. There are increasing threats from npm, rogue components, and we've been able to leverage protection there. We also really like being able to know which of our apps has known vulnerabilities. 

Specifically features that have been good include

• the email notifications
• the API, which has been good to work with for reporting, because we have some downstream reporting requirements
• that it's been really user-friendly to work with.

Generally speaking, the configuration of all the tools is pretty good; the admin screens are good.

We have been able to use the API for some Excel-based reports to compare how many of our application deployments were covered by scans, and to do charts on that. That has been good and worked really well.

The default policies are also good. We deviated a little bit from those, but we have mostly used them, and they have been good. They provide us with the flexibility that we need and probably more flexibility than we need.

It has brought open source intelligence and policy enforcement across our SDLC. We have policies and SLAs that say, for example, critical findings have to be fixed within 90 days, and "high" findings have to be fixed within 120 days. That's tracked and reported on. We use the API to do some downstream reporting into some executive dashboards and when executives see red and orange they don't like it, and things get done. We've also made it part of our standards to say no components with existing vulnerabilities. Enforcing those standards is integrated into our software development life cycle.

Sonatype also blocks undesirable open source components. That is also done through policies that you can set, and configuration of the repo.

The integration is one sore spot, because when we first bought the tool they said JavaScript wasn't really part of the IDE integration, but it was on the roadmap. I followed up on that, and they said, "Oh, you can submit an idea on our idea site to have that added." The sales team said it was already in the pipeline, but it was actually not in the pipeline. 

Overall it's good, but it would be good for our JavaScript front-end developers to have that IDE integration for their libraries. Right now, they don't, and I'm told by my Sonatype support rep that I need to submit an idea, from which they will submit a feature request. I was told it was already in the pipeline, so that was one strike against sales. Everything else has been pretty good.

Also, when Nexus Firewall blocks a component, it doesn't really give us a message that tells us where to go; at least it doesn't in our setup. I have to tell all the users, "Here's the URL where you can go to look up why Firewall is blocking your stuff. And that is odd because when it finishes a scan, the scan results give you the URL. But when you get blocked by Firewall, it doesn't give you the URL where you can go look that up. You can definitely work around that, but it's a bit strange. It's almost like something they forgot to include.

I've been using Sonatype Nexus Lifecycle since October of 2019.

We've only had the server go down one time in about two years, so that's good.

The scalability is fine, as far as I can tell. We only have so many developers, and haven't really grown our development teams at all in the past few years. We have about 200 users of Sonatype who are either developers or application security or myself as senior architect. We haven't had problems with capacity, but we haven't had to scale it.

It does seem to scale okay for adding new software artifacts, because we continue to add more stuff to it.

Overall, tech support is good.

When submitting a support ticket, I've seen other vendors basically regurgitate what the tool is saying, instead of actually looking at what I'm trying to say. Sonatype has done a good job of at least saying, "Yeah, we looked at this pull request on this open source component, and this is where we're seeing something. I have even had to coordinate a discussion between an open source maintainer, Spring Pivotal, and Sonatype, to let them hash out who's right.

We used OWASP Dependency-Check. It's a good resource for security standards and, occasionally, free tools, and it was a good command-line checker. It matched heuristically, so it would find a lot of false positives. It got us started and gave us an idea of how much debt we had, so it was useful. It just required a lot of tuning to weed out false positives.

They have good documentation about how to configure things and get it set up, and it's easy to find what you're looking for, generally speaking. I found the setup to be pretty straightforward. I had to spearhead that effort, solo, and get it socialized out to all the teams. Most people seemed to be able to configure it pretty well without a lot of hand-holding. The rollout went really well.

We run it on our own Windows box. It's a little tricky to get it to run as a Windows service, but they have instructions for it and we finally figured out how to get that working. I think they intend for it to be run on Linux, but it's Java, so it runs on either. It's running fine on Windows.

I just used the online documentation and did it all myself. It took about three months to roll it out.

How do you prove that you've not gotten hacked because of the tool? We've definitely gotten better visibility into how we're using older components and when we need to migrate away from them. We're much better positioned now to keep things patched and if there's another Struts 2, armageddon-type vulnerability in a library we use, we'll be much quicker to get on it.

It's like any security tool. How do you know that the door lock paid for itself? You really don't know who would have knocked your door down. But once our developers get more used to the tool over time and we get the technical debt driven down, they will be more productive in terms of making sure the libraries are up to date.

In the meantime, when they're onboarding and trying to figure it out, it's going to slow them down a little bit, to get oriented. If they're dealing with a legacy of technical debt and there are a lot of things that have to be fixed, because nobody has updated an internet app in 10 years, it's not going to make them more productive. But if you're willing to pay down that technical debt, it's totally worth it, but it's hard to quantify. But if you consider keeping your apps up to date as productivity then it helps with productivity.

It's expensive, but you get what you pay for. There were no problems with the base license and how they do it. It was transparent. You don't have to worry. You can scan to your heart's delight. They're pretty much based on co-contributing developers, so if you have auditors or AppSec, that doesn't count against your total.

We're not using their Advanced Development Pack because it costs more money. That is a sore spot. We're not using the Infrastructure as Code Pack or the Advanced Legal Pack because there hasn't really been a lot of appetite to use the DLC mode. That's a criticism I have of Sonatype. I understand they want to get paid, everybody does, but they're adding new features to the product as add-on purchases, as opposed to just improving the product. You pay for a subscription to the product. If we had bought a permanent license and we weren't paying a subscription, I could see it working that way. But I don't like the fact that we pay a subscription but we're not getting these features because they want to charge more for these packs.

I have told them that. I have said, "I don't like this model. We're paying you guys a lot of money already. Why are we having to be quoted to pay even more?" Maybe our subscription only pays for the data and the support, and if so, that's fine, but they weren't very transparent. They're saying, "Hey, we're going to be developing new features and capabilities, but they're going to cost more." As far as vendors go they're a good vendor, but this is one thing that they started doing that I don't like.

I don't like the whole "pack" mentality they've got going now. "We're going to come up with cool new features, dangle them in front of you, and then say, 'Hey, we know you're already paying a bunch of money per year for a sub, but you're going to have to pay more if you want this.'" It rubs me the wrong way.

They only started coming out with these packs in the past year or so. I'll say, "I wish the product did this," and they'll say, "Oh, we're working on a pack to do that, but it'll cost money." I had to move mountains to get the money to pay for the base product. It's not cheap. I don't know if they think we've got a money printing machine hiding in the back, but we don't.

The solution's data quality is good. It's a lot better than what we had before, which was OWASP Dependency-Check. That was okay, but just okay. Sonatype seems to have higher fidelity, but there have been times when I've had to reach out and say, "Hey, is this a false positive? It seems a little off." Sonatype's data research team seems pretty good. It's good data, for sure, but they're also willing to accept feedback on it, and that's good too.

If we can't afford Sonatype in 2025, we might go back to OWASP.

We briefly used SourceClear. We didn't use it very long. It wasn't very good. It seemed that the quality of data wasn't as good. There were no IDE integrations and more false positives. It was totally cloud-based. I'm not sure if the guys who set it up configured it correctly, and that might not be their fault. But we had a lot of issues with it breaking builds and just not working correctly. The reliability and uptime wasn't good. But the biggest problem was probably that they charged per scan, as opposed to per app or per developer. You couldn't really scale to let your developers scan locally without worrying about blowing your budget. The whole licensing model for SourceClear was bad.

Make sure you know what packs you're getting with your buy. They also tried to sell some sort of training about how to customize policies, training that they didn't include in the original estimate. So make sure whether your quote includes packs or not and whether you need training for an administrator or whether they'll be able to self-serve from the documentation. It was like we were in the checkout line and then they asked, "Would you also like this training?" instead of including it in the original estimate. It's annoying. If that is part of the package, let us know how much it costs up front, in our estimate, and we'll decide. Don't try to bolt it on midway through the purchase process, which is what they did.

Depending on how old your code set is, brace yourself. You're going to have to figure out a way to report on the stuff. You're going to have to figure out a way to socialize the value, and you're going to have to constantly answer questions about, "How should I fix this?" My advice would be to make sure you have a champion who not only knows how to administer the tool, but who knows enough about software development to help provide guidance about how to remediate issues. I feel that if I didn't have both of those skill sets, this would have been a complete flop, just another tool rotting on the shelf.

When it comes to data quality, occasionally it helps us solve problems faster, but sometimes it creates confusion because their data team tries to monitor above and beyond the National Vulnerability Database. Occasionally you get conflicting messages between that and what Sonatype is saying. They're trying to go above and beyond and say things like, "Hey, the bulletin says it's version four or five, but we see it's in version three." But it can get a little confusing when the maintainers don't agree with Sonatype. It's not Sonatype's fault. They're trying to cover for the maintainers not being really thorough with their notifications. 

But when they come into conflict, it is confusing for the end-user because you're trying to figure out, "Well, what do I really need to do here?" But overall, most of it is really straightforward. The technology can be confusing, but that's software libraries and their features. All that stuff can be confusing, period. But that's not because of how it's communicated, rather it's because it's complicated technology. For example, the vulnerability might be talking about the second-tier cache and that's something I've never even heard of, so I have to go research it. But generally, their communication is effective.

We have two use cases. We're predominantly a products company and we scan our products, in a controlled way, to make sure they're not using open-source software. We want to make sure that we're licensed correctly for our products and the way they are deployed. There are also security reasons for making sure that our products aren't introducing vulnerabilities and, if they are, that we can address them. 

And part of our business is that we build bespoke software. Some of our customers want to make sure that the open-source software is being used correctly in the software we build for them. And, again, we want to protect that software against security vulnerabilities that might be introduced by open-source software.

We also use the solution to help with open-source governance and minimize risk. When we are acquiring a new company, for example, we will automatically, as part of the due diligence on that purchase, scan their products to make sure they don't have vulnerabilities that we are not prepared to accept. So it helps us to make sure, before we make any purchase, that the target acquisition is of suitable quality, in terms of its open-source use.

The solution has improved the way our company functions in terms of the way that developers think about the components that are being built into their products, making sure they're not being duplicated, for example. The developers now understand that there's a cost associated with including open-source. It may not have a licensing fee, but there is a cost associated with it. That sort of education piece has had a big influence.

It has also brought open-source intelligence and policy enforcement across our SDLC. As the teams are setting up their development environments, we have now gotten them to build Sonatype into their development pipeline. They scan their codebase so they actually catch things at the point that they introduce new, open-source software into the products, to make sure they're not actually introducing vulnerabilities or licensing-policy breaches.

Sonatype has also reduced our risk in releasing secure apps to market. Previously, teams would just release without knowing what risks it was exposed to. Now, we can actually do a better risk assessment.

For us, it's seeing not only the licensing and security vulnerabilities but also seeing the age of the open-sources included within our software. That allows us to take proactive steps to make sure we're updating the software to versions that are regularly maintained and that don't have any vulnerabilities.

In addition, the default policies, in general, are quite good. We have adjusted slightly but we're fairly happy with the way that's set up. They provide us with the flexibility we're looking for.

The data quality is pretty good. We don't have masses of false positives. There have been some areas around .NET which haven't been quite as good as some of the other areas, but we know work is being done on that. Overall, the data quality does help us solve problems faster.

We use Azure DevOps as our application lifecycle management tool. It doesn't integrate with that as well as it does with other tools at the moment, but I think there's work being done to address that. In terms of IDEs, it integrates well. We would like to integrate it into our Azure cloud deployment but the integration with Azure Active Directory isn't quite as slick as we would like it to be. We have to do some workarounds for that at the moment.

Also, the ability of the solution to recognize more of the .NET components would be helpful for us.

I've been using Sonatype for about six years.

It's a stable product, especially compared to some of its competitors.

The technical support is generally good. A couple of years ago there were some things that had been logged and that had to be chased a few times. They didn't go as quickly as we'd have liked. But recently, things have been better and they have been more timely in their responses.

Our company tried with Black Duck, but that was it.

The initial setup was straightforward. One of my team members was able to execute it quite quickly without too much trouble or additional help.

It's deployed internally at the moment but, moving forward, we want to move it to a cloud-based deployment.

We have seen return on our investment, but it's a difficult one to quantify because, unless you have a problem, it's like any sort of security or testing; it's difficult to quantify unless you have an issue. In terms of protecting our IP it certainly has provided ROI and, in security issues as well, it has helped us to identify them, reducing our risk. There has been a big risk reduction for us.

We pay on a yearly basis.

We do a supplier selection every couple of years. One solution that we've evaluated is Black Duck, for example, but it didn't seem to be as stable as the Sonatype solution, when we last tested it.

WhiteSource is another one we tested. It's a cloud-hosted solution so I can't comment on its stability.

Comparing these solutions with Sonatype, the information that comes with Sonatype and its recognition are good. The fact that WhiteSource is cloud-hosted is nice and it's an advantage you don't immediately get with Sonatype. But with WhiteSource we got more false positives than we did with other tools. And Black Duck, when we've last reviewed it, wasn't as comprehensive as what we are looking for.

Sonatype met our needs, what we were looking for, particularly around protection of IP. The knowledge of the Sonatype team, and our good working relationship with them, have helped us to continue to use the product. The fact that they take some of our feedback and incorporate it into the product has also helped.

I would definitely recommend understanding what you're trying to achieve. For us it's quite clear that we want, for the moment, to protect our IP and to identify security vulnerabilities. If the understanding is that you want to protect against open-source from coming into your products in the first place, or you're doing greenfield development, look at the right product stack from Sonatype to make sure that you're choosing the right set of products. We've got a mature product base that we're working with. If you're starting from scratch, you would want to assess what you're trying to get out of your policies and processes around this, and make sure that the products match.

We have about 150 users of Sonatype in our company, and their roles range from managers who review the open-source solutions to make sure they're being licensed properly in the product, to developers who are actually cutting the code. It's also service and project managers looking at their exposure, or maybe the audit team that wants to make sure that there's compliance within the different teams. For deployment of the solution and maintenance we have one person, a junior software engineer.

Sonatype is being used for regular scans on our priority projects, numbering about 20. We plan to eventually get that rolled out much more of our estate, to 50 or 60 business units.

I would rate it at seven out of 10. Some of the scanning around the .NET open-source licensing, the recognition; and the integration with some of our development tools, like Azure DevOps, are where, perhaps, it's lacking.