Sonatype Lifecycle Reviews

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.

We're using Sonatype Nexus Lifecycle to scan for vulnerabilities in our continuous integration and deployment pipelines. We're also using the solution as part of our IDEs for developer support.

Due to the sheer amount of vulnerabilities and the fact that my company is still working on eliminating all vulnerabilities, it's still too early for me to say what I like most about Sonatype Nexus Lifecycle. Still, one of the best functions of the product is the guidance it gives in finding which components or applications have vulnerabilities.

For example, my team had a vulnerability or a CVE connected to Apache last week. My team couldn't find which applications had the vulnerability initially, but using Sonatype Nexus Lifecycle helped. My team deployed new versions on that same day and successfully eliminated the vulnerabilities, so right now, the best feature of Sonatype Nexus Lifecycle is finding which applications have vulnerabilities.

It could be because I need to learn more about Sonatype Nexus Lifecycle, but as a leader, if I want to analyze the vulnerability situation and how it is and the forecast, I'd like to look at the reports and understand what the results mean. It's been challenging for me to understand the reports and dashboards on Sonatype Nexus Lifecycle, so I'll need to take a course or watch some YouTube tutorials about the product. If Sonatype Nexus Lifecycle has documentation that could help me properly analyze the vulnerability situation and what the graphs mean, then that would be helpful.

I need help understanding what each graph is showing, and it seems my company is the worst, based on the chart. Still, I need clarification, so if there were some documentation, a more extensive knowledge base, or a question mark icon you could hover over that would explain what each data on the graph means, that would make Sonatype Nexus Lifecycle better.

I've been using Sonatype Nexus Lifecycle for almost a year.

Sonatype Nexus Lifecycle is a very stable tool; my team hasn't had any issues with it. My company had a significant outage two or three weeks ago, so all storage was lost. Still, in just a short while, Sonatype Nexus Lifecycle was up again, which makes Sonatype Nexus Lifecycle a very good tool.

We haven't scaled Sonatype Nexus Lifecycle yet.

We've just been using Sonatype Nexus Lifecycle, so we can't evaluate its technical support for now.

Sonatype Nexus Lifecycle was the first tool we used with dependency scanning functionality, though we used other vulnerability scanning tools such as Docker and Trivy before Sonatype Nexus Lifecycle. We also scanned for vulnerability in images with Harbor. Sonatype Nexus Lifecycle is the only tool we've used for scanning dependencies.

The initial setup for Sonatype Nexus Lifecycle was straightforward.

We deployed the Sonatype Nexus Lifecycle in-house. We learned how to install and use the product.

We've seen ROI from Sonatype Nexus Lifecycle, mainly connected to the number of attacks. For example, we've calculated the number of hours our employees put into analyzing a vulnerability and looking for that vulnerability in the different components. We saw that the main benefit of using Sonatype Nexus Lifecycle is quickly finding which components have vulnerabilities. As a result, two to three employees save on a week's work because that's how long it takes to look through all the different components with vulnerabilities.

Vulnerabilities could also cause a significant outage or complete data loss, which comes at a high price. Sonatype Nexus Lifecycle could help prevent that or help eliminate the risks. Hence, there's ROI from the tool, but we still need to evaluate the data fully.

In comparison with other tools, Sonatype Nexus Lifecycle could be more expensive. Still, at the same time, my company prioritizes security, so the pricing for Sonatype Nexus Lifecycle hasn't been an issue.

If IT security weren't at the top of the list for my company, somebody would have raised the question about cost and how Sonatype Nexus Lifecycle is in terms of ROI. So far, there's been no question about the price. The cost of Sonatype Nexus Lifecycle hasn't been a problem so far.

My company pays for the license yearly, plus technical support.

We started evaluating four different tools about this time last year, from November to December, and we chose Sonatype Nexus Lifecycle. We were deciding between Snyk and Sonatype Nexus Lifecycle. Still, Snyk lacked support for all our technologies and didn't have the same IDE support available in Sonatype Nexus Lifecycle, so we went with Sonatype Nexus Lifecycle.

We used Sonatype Nexus Lifecycle during the first quarter, from January to February, to establish the tool in our organization and set it up. We then made a training plan and, from March to April, rolled the Sonatype Nexus Lifecycle out to all the teams, but the different teams also had to build their pipelines, so there have been delays from May to the present. We've been pushing them to adjust their pipelines and still helping them.

My company is currently using the latest version of Sonatype Nexus Lifecycle.

About fifty IT department employees use Sonatype Nexus Lifecycle in my small company.

There's no plan to increase the usage of Sonatype Nexus Lifecycle. Its rollout is complete, and only the development teams use the tool within the company.

My rating for Sonatype Nexus Lifecycle is eight out of ten because it does its job, and my team hasn't had any problems with it.

I'd recommend Sonatype Nexus Lifecycle to others.

My company is a Sonatype Nexus Lifecycle customer or end-user.

We basically use it for open-source vulnerability. It is completely on-premise as of now, but we will be exploring other options.

IQ Server is part of BT's central DevOps platform, which is basically the entire DevOps CI/CD platform. IQ Server is a part of it covering the security vulnerability area. We have also made it available for our developers as a plugin on IDE. These integrations are good, simplistic, and straightforward. It is easy to integrate with IQ Server and easy to fetch those results while being built and push them onto a Jenkins board. My impression of such integrations has been quite good. I have heard good reviews from my engineers about how the plugins that are there work on IDE.

It basically helps us in identifying open-source vulnerabilities. This is the only tool we have in our portfolio that does this. There are no alternatives. So, it is quite critical for us. Whatever strength Nexus IQ has is the strength that BT has against any open-source vulnerabilities that might exist in our code.

The data that IQ generates around the vulnerabilities and the way it is distributed across different severities is definitely helpful. It does tell us what decision to make in terms of what should be skipped and what should be worked upon. So, there are absolutely no issues there.

We use both Nexus Repository and Lifecycle, and every open-source dependency after being approved across gets added onto our central repository from which developers can access anything. When they are requesting an open-source component, product, or DLL, it has to go through the IQ scan before it can be added to the repo. Basically, in BT, at the first door itself, we try to keep all vulnerabilities away. Of course, there would be scenarios where you make a change and approve something, but the DLL becomes vulnerable. In later stages also, it can get flagged very easily. The flag reaches the repo very soon, and an automated system removes it or disables it from developers being able to use it. That's the perfect example of integration, and how we are forcing these policies so that we stay as good as we can.

We are using Lifecycle in our software supply chain. It is a part of our platform, and any software that we create has to pass through the platform, So, it is a part of our software supply chain. 

Its engine itself is most valuable in terms of the way it calculates and decides whether a security vulnerability exists or not. That's the most important thing. Its security is also pretty good, and its listing about the severities is also good.

The plugins that are there on the editor are also valuable. Engineers don't have to wait for the entire pipeline to go in and show some results. While they are writing code, it can stop them from writing something that might end up as a security vulnerability.

Its default policies and the policy engine are quite good. So far, we haven't found anything that went through IQ but wasn't caught. We are quite happy with it. The policy engine pretty much provides the flexibility that we need. I haven't seen a case where any of my customers came in and said that they don't have a certain policy in place for IQ, or they wanted to change or remove any policies. At times, they wanted to suppress warnings or altogether skip them if possible, but it doesn't happen or is required very often. 

One area of improvement, about which I have spoken to the Sonatype architect a while ago, is related to the installation. We still have an installation on Linux machines. The installation should move to EKS or Kubernetes so that we can do rollover updates, and we don't have to take the service down. My primary focus is to have at least triple line availability of my tools, which gives me a very small window to update my tools, including IQ. Not having them on Kubernetes means that every time we are performing an upgrade, there is downtime. It impacts the 0.1% allocated downtime that we are allowed to have, which becomes a challenge. So, if there is Kubernetes installation, it would be much easier. That's one thing that definitely needs to be improved.

Some of our engineers came from outside of BT, and there are some features that they are used to from rival products, but they are currently not there in Sonatype IQ. For example, Snyk has a feature to stop a particular check-in from happening at the merge stage in case something is different or wrong. This feature is still in the development phase in IQ. Such a feature would be handy in IQ.

Another area where Nexus can severely improve is the licensing model. I am not worried about the licensing cost, but the way they calculate the number of licenses being used needs to be improved. They have been quite ambiguous in terms of how they calculate who is using Nexus or IQ, and this ambiguity has not been good. At times, we think we have a certain number of customers, but Sonatype says that it is not true, and we have some other number. They haven't been able to explain very well how they calculate that number, which has been a challenge for us.

BT has been using Nexus solutions for almost three years. I myself have been associated with Nexus for two years since I joined BT.

IQ Server is quite stable. I get a report from my team about the availability of my tools, and IQ Server stands pretty great. Its stability is 99.99% for sure. 

Repo has had some challenges with our setup. I'm not sure if that has to do with Repo itself or our own infrastructure. There have been some challenges, but there is nothing noticeable. So, overall, they have been quite good. The only thing is that whenever we have to update the tool, there has to be mandatory downtime, which I would like to avoid with something like a Kubernetes-based system.

I haven't faced any challenges in the scalability of Nexus solutions. We have gone from pretty minimal usage to pretty high usage, and I haven't seen any challenges. It is good. It is not similar to some of the other tools that I have where scalability has been an issue.

We have around 3,000 to 4,000 engineers who use Repo daily. We have around 1,000 to 2,000 users who use IQ Server. Our usage is moderate. It is not extremely heavy. As compared to the other tools that are being used by around 30,000 engineers, the usage of Nexus is not heavy. It is moderate.

My team works more closely with them, but I do get feedback from them. I have worked with their architect, Sola, multiple times, and I can easily rate him a nine out of 10. He has been pretty good. The architecture that he provided has been crystal clear around what we have here in BT. Whenever there was a problem with Nexus Repo, he came to the rescue. He understood what the problem was and could fairly quickly implement it. It provided more help than support. We were trying to scale Nexus to a certain extent, and he was able to assist us quite well. The only area where I felt I did not get what I needed was related to licensing. They have been quite ambiguous in terms of how they calculate the number of licenses, and even he couldn't clearly tell me how the calculations are done. Other than that, he has been fantastic.

Its initial setup was done by someone who is retired now. He did it five or six months before I joined.

For its maintenance, we have a team of three people. We have one SME and two support engineers who are dedicatedly there for Nexus and any services that we do through Nexus.

Our ROI is moderate. It has definitely helped us in avoiding a lot of security miscues., but the adoption of IQ hasn't been as much as I would have liked. It has nothing to do with Sonatype. It has more to do with BT's culture and BT's engineers adopting it.

Given the number of users we have, it is one of the most expensive tools in our portfolio, which includes some real heavy-duty tools such as GitLab, Jira, etc. It is definitely a bit on the expensive side, and the ambiguity in how the licenses are calculated adds to the cost as well. If there is a better understanding of how the licenses are being calculated, there would be a better agreement between the two parties, and the cost might also be a little less. 

There is no extra cost from Sonatype. There is an operational cost on the BT side in terms of resources, etc.

We have evaluated Snyk but not for the same capabilities that IQ has. We didn't evaluate Snyk for open-source vulnerabilities. We evaluated it for container security, Infrastructure as Code security, and other aspects. Snyk does OSS as well, but we are not looking at OSS as a solution offering from Snyk at this time. We are doing a pilot with Snyk to see how they can do other things.

In terms of the open-source vulnerability checks, Snyk has a few more features around stopping mergers to happen and stopping check-ins to happen with integration with Git. This is not something that we have evaluated. It came as feedback from our engineers.

It is quite easy to integrate across the tooling board, but that it does lack a couple of modern and shiny features. It does a pretty good job around the core things of open-source vulnerability check, and it categorizes vulnerabilities pretty nicely. To anybody who wants to use Nexus, I would advise seeing how they can create a bit of a scalable and multi-instance model between IQ and Repo so that they can save on some of the update time that I have to go through.

It has delayed some of the deployments across our supply chain, which is not necessarily a bad thing because delay is only in the case it identifies any issues. One of the challenges in terms of adoption has been that not everybody wants to know how bad their code is. It has been a challenge to make more and more people adopt Nexus IQ, but the quality has definitely improved for those who have onboarded it. There is no doubt about that.

In terms of the reduction in the time taken to release secure apps to market, it doesn't improve the time if you look at a small picture and a single pipeline or component. It reduces time if you look at the larger picture in terms of how many cycles would have been there if you had identified a security vulnerability in the final environment rather than the earlier environment. In such a scenario, it saves time. It doesn't save time in making the code reach production quicker, but it saves time with fewer cycles happening between the development code and the production code. If I go completely by the test count or the engineering count of around 2,000 folks, there is definitely a saving of around 4,000 to 5,000 hours every quarter.

It has not increased the level of productivity for our developers because that's not why we are using Nexus. It has definitely reduced the number of cycles between the production code and the development code.

We don't use the Nexus Container feature. We have a different container that is our own instance. It is a strategic instance for BT that is owned by our own team.

Nexus definitely has been a key component in our portfolio. The big lesson that I have learned from using Nexus is that there are a lot of open-source libraries that are considered okay in a common area. A lot of times, we identified a library that almost everybody considers okay to use but then realized its vulnerability. So, one of the lessons is that you have to be vigilant all the time with what you are using inside your code.

I would rate it an eight out of 10, and that's quite good. I have deducted two points. One of them is related to the licensing model, which should not be that ambiguous. Another one is related to becoming more forward-looking and supporting modern products such as Kubernetes or EKS. The demand of the hour is to have our services up for more than four-nines or five-nines. 

It's mainly used to scan for security issues in any components that we use. There are two parts to it, the license part and the security part. We use it generally for the security, but we also do have scans for the license stuff too.

One of the ways that it has helped us is that it has given us visibility into security issues. It has made us a bit more proactive in dealing with things. Before, we depended on how much news there was about a particular issue in a component, just learn about it. And when we learned about it, we didn't know which applications we had that were affected by it. Lifecycle helps really well with that. 

We put it into our pipeline. Whenever a developer builds, he can choose to do a scan - we don't enforce it. But what we do enforce is that when a developer makes a change in the repository, which means pushing it into production, as part of the build pipeline we scan it to make sure they are not introducing anything new in there. That has been a really good feature to make sure we've got that base level of hygiene.

It also has something called continuous scan. We run that every night and scan our build materials - all the components that we know we are using, based on the previous scans. We re-scan them to see if any of them have any new vulnerabilities that have been detected. That is really beneficial because in our company we're always building new applications, and some of them are more actively developed than others. What we found was that we had a lot of vulnerabilities in applications that weren't being actively developed, things that needed to be fixed. If it weren't for Lifecycle, they would have just fallen off our radar.

It has brought open-source intelligence and policy enforcement across our SDLC. We have two kinds of build pipelines. They are centrally managed by a team which handles all the build infrastructure. We integrated it so they have to do those scans. The policy enforcement will break a build, so you can't move forward without addressing it. The solution blocks undesirable open-source components from entering our development lifecycle, based on the policies that we set. It will break the build straight away. There's no way you can ship code that introduces new vulnerabilities. We just don't allow it at all.

It has improved our security but, in terms of developer productivity, if you asked the developers about fixing security issues, I don't know if they would consider that productive for them. But from my point of view, it has improved developer productivity.

There are two things that allow us to do what we want to and that's why we chose Nexus Lifecycle. 

First, it scans and gives you a low false-positive count. When we were looking for a product to solve this need, we looked at different products, Nexus Lifecycle being one of them. The reason we picked Lifecycle over the other products is, while the other products were flagging stuff too, they were flagging things that were incorrect. Nexus has low false-positive results, which give us a high confidence factor, which is something we like about it.

The other thing that we thought that was really good about it was that it gives an overview. We find something that has a vulnerability and say, "Hey, what can I upgrade to?" What's really nice about that is it shows us a graph of all the versions for that particular component, and it marks out the ones that have a vulnerability and the ones that don't have a vulnerability. It also shows the popularity, so we can look at it and say, "Alright, from where we are, what is the next version that we can move to that is not vulnerable and that is quite popular?" If it's popular, we tend to prefer it because then more people are looking into it, and it gets a bit more scrutiny.

We created a Wiki page for each team showing an overview of their outstanding security issues because the Lifecycle reporting interface isn't as intuitive. It is good for people on my team who use it quite often. But for a tech engineer who doesn't interact with it regularly, it's quite confusing. We did that because we got so many questions about it all the time.

There are other areas for improvement. 

The most recent one - something I haven't shared with Sonatype yet but I intend to - is with the creating of defect tickets. The solution has something that is really useful, its integration with JIRA, and it creates tickets if there's an issue. What I thought would be really good was, from the moment we break builds, there is no way to track, from a management perspective, how we are doing. We are looking at creating tickets. The problem with the tickets, which is the where there is room for Sonatype to grow, is that there is no flexibility in terms of customizing the entries in the tickets. There are certain things they put in for you, they tell you what application it is, but what I'd really like to be able to do is say, "Fill in this field with the name of the application. Fill in this field with the name of the owner. Or set a due date to be X days from when it was raised. They don't allow that. They allow hard-coded values across everything in Nexus IQ. It doesn't work well because the tickets created depend on the use case. We would like to create these tickets and give them directly to the teams that have to look after them. We want to be able to assign them to the right person, based on the application that is used. " We are looking at finding ways to integrate with it because they don't have that.

Another feature they could use is more languages. Sonatype has been mainly a Java shop because they look after Maven Central. And we have been mainly a Java shop in development. But we've slowly been branching out to different languages. They don't cover all of them, and those that they do cover are not as in-depth as we would like them to be. They don't have the same level of coverage as the main language, which is Java.

The stability has been pretty good. We're pretty happy with it. There have been no issues there.

Scalability is not an issue. We have a microservices architecture and we've got about 150 applications in there and we scan them quite regularly. When we first started, we had a lot fewer applications, we were sending about five gigs of scanning data requests to the Sonatype servers every day. They were able to handle that. We had issues before, but I think they were more networking configuration issues, and they could have been on our side. But that has all been resolved and there are no issues.

Their technical support has been pretty good. They're based in the US and the turnaround time tends to be overnight. We generally send out requests in the afternoon and we normally hear back from them when we come into the office the next day.

The depth of the responses vary, although it's generally pretty good. Sometimes they just don't have enough information, and that could be that from our side, that we have not provided enough information, enough context. But generally, it's been alright.

We had a few issues initially when we set it up. We had a problem with not having enough space because it would keep the reports indefinitely. We were running out of disk space. But I know they've addressed that now because, in one of the updates that we did last year, the disk space was reduced considerably. They've been telling me that they were actively looking into it.

The initial deployment took a few days. Most of the challenges that we had for the deployment were mainly to do with the rollout of our policies. Imagine an application that never had any scans, and we wanted to get to this SLA model, where you shall not introduce any more vulnerabilities and you need to fix existing issues. What took so long was we had to turn on the policies slowly and we had to grandfather everyone. Otherwise, everyone would just stop working straight away. When we first turned it on we discovered so many vulnerabilities in there that we never knew existed before.

The implementation strategy was not to have the SLA initially - how long you had to get something fixed. We turned the solution on and said you can not introduce any more new components that have vulnerabilities. We drew a line in the sand and said, "That's it." Then, we created a list of all the things that we knew were a problem - that was a very manual process. We started from the top saying, "What are the critical ones that we will work on with teams to try and address them?"

Some of the fixes were not trivial, they were quite a big change. One of the reasons was because, being an old application, it was using really old versions and the fix required a newer version. But the jump from where you were to where you needed to be was quite a big jump. That resulted in quite a lot of backward incompatibility with the other components in the system. That was what took a lot of time. We worked our way down. It took us a good year-and-a-half to get to where we wanted to be because we were competing with product engineering time to either work with features or fix security. We needed to find the right balance.

For deploying it there were two people from my team to set it up and get it all going. And to address the issues it was a combined effort within the whole company. In terms of maintenance, now that it's configured, we have one person a week who is on the support roster to address any issues that we have. The maintenance is more to field questions the engineering team might have. They may say, "Hey, I just got this report that this application has an issue. Can I have more information about it?" Maintenance isn't about maintaining the system, it is more about providing consultation to teams and advising them on how to fix those issues that have been discovered.

The area where we've seen ROI is security hygiene. We're using a lot fewer vulnerable libraries. What we have seen is that when there is news about something that is vulnerable, and that there is a tool that someone has created that allows you to exploit it, we normally already know about it and we've addressed it. There's peace of mind knowing that we're on top of it.

We're pretty happy with the price, for what it is delivering for us and the value we're getting from it.

We did a PoC with a few companies and we picked Sonatype and we've been happy with them since.

We looked at Black Duck, and we also look at the free version, the OWASP, a dependency checker. We also looked at Veracode. The difference between Sonatype and the competitors is the accuracy. But having said that, I'm not too sure how Lifecycle compares to Black Duck. I know Black Duck is pretty good too. The main difference between Lifecycle and Black Duck for us was the price point.

My advice is that you should definitely use it. You need to think about the rollout and to make sure you integrate it into the software development lifecycle. That's where you get the most value because it provides quick feedback for developers. Be mindful of the rollout and breaking the builds. I don't think other companies that we spoke chose to break builds, but we do that and that is a sensitive topic for developers if you choose to do that.

We don't use the application onboarding and policy grandfathering features at all. I suggested that to them, but the main reason we don't use them is, while we had that problem when we started out, we don't have the problem anymore.

We don't use the Success Metrics feature as much. When it first came out I was quite excited about it, I thought it would be quite useful. But it hasn't really been as useful as I would have liked it to be. I was going to use it for figuring out trends. I was hoping to figure out how are we are tracking the number of vulnerabilities being discovered, and the trend, over time in terms of: Are we actively addressing them? I was hoping to break that down to engineering departments so could create a report and say, "Hey, this particular department has been really good, they're actively fixing vulnerabilities as they're coming out. This other department could be a lot better." I was hoping to get that, and it kind of had that. To be honest, I haven't looked at it for quite a while. But when I first looked at it, it looked quite good, but I didn't understand quite a bit of the graphs. I ended up using my own data set instead.

We do have metrics on how much faster it helps us to fix issues but that's more because we have a company policy, we have an SLA there. It's based on the severity of the issue. There is a CVSS code. We map that into criticality, so if it's a ten, we say it's a severe security issue. There are ranges: critical, high, medium, low. This is actually mapped out to some standard policies that come with Nexus Lifecycle when you first install, so we just kept that in there because we thought that was best practice. 

But what we did say is that if there is anything that's critical, we want the team that's looking after the application to immediately stop work and address it straight away. If it's a "high," they have one month to address it. If it's a "medium," they've got three months, and if it's a "low," they've got six months. That's how we choose to address it, but that's set by us and it's enforced by Lifecycle. 

We have done something to integrate with it. It's not part of the feature set that it has. We integrated with it such that when we do discover something that's new - nothing that's introduced; rather something that's already in there that was okay yesterday but isn't okay today - we put a policy waiver (which is the term they use in Lifecycle) in place so it doesn't break the build. Once that SLA has expired, it will break the build and teams cannot make any more changes until they address it. That helps us conform to the SLA.

The data quality is generally pretty good. We're pretty happy with it. We have seen a few cases in the last year where there were things that came out, and the teams came to us and said, "Hey, it's saying this, but we investigated further, it's not really an issue." So we've gone back to Sonatype and told them about these things. But, having said that, across the board, we feel that Nexus has been the most accurate so far, compared to all the other ones that we have used.

It integrates fairly well with our existing DevOps tool. We had to do some work to get the metrics that we can show teams. We had to do some work to hand it the SLA stuff that we want our teams to go by. We are trying to do some work now where we want to create a defect ticket automatically. It hasn't been very good at that. It has some basic functionality but not as good as what we want. But generally, I would say it's good. I would also add that I don't think that it's any better or worse than the other products out there. It's doing all right.

The primary integration was to enforce our SLA. The other integration we have done is we created another tool that acts as a proxy. There are applications and applications belong to a team. It allows us to give immediate feedback to the teams. When the teams choose to build it locally and they run this tool, they don't use the Lifecycle tool, they use this tool that we wrote. The reason why we did that was for our SLA, because then the report comes back to the team. It actually shows them how many days remain for those things that are subject to the SLA.

We also did some work to create a Wiki page, one for each team, that we update every day. This is more to give to team leaders, who are not always on the code, an overview of what the outstanding security issues are, in which applications they are found, and how much time they have to fix them.

Regarding the time it takes to release apps, it hasn't changed the amount of time. We would like to move to continuous deployment but, at the moment, some of them are continuous and some are weekly and this has had has no impact on that.

We have about 135 users of the product in our organization. Software engineers are using it, DevOps engineers are using it, we've got some testers using it. We also have some delivery managers using it and they're using it more for the reporting to see how things are going. We also have some operations people using because it can also scan containers.

It has been utilized quite extensively. I don't think it's going to increase any more. It would increase if we had more applications, but we are also using a lot more technologies.

I give it a nine out of ten because of the accuracy. I like the information that it provides in terms of how to address issues. It would have been a ten, but there are other things that require integration, the extra stuff that we had to do, which I wish we didn't have to do, that it was all done for us. But we're probably not using it in a way that they envisioned most people would use it.

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 have it running on the majority of our builds for all of our applications and we use Jenkins for our build system. Eventually, the goal is to incorporate this into Jenkins so that if we don't get a good enough result on both Nexus IQ and SonarQube, we'll actually fail the Jenkins build. That way we force ourselves to maintain good metrics on both of them. So Nexus IQ is making sure that we're using dependencies that don't have known vulnerabilities. And SonarQube is making sure that our code maintains a certain level of quality.

Unfortunately, we haven't been able to take full advantage of Nexus. It's set up and it's working, but we haven't rolled it fully into our development process. Our builds use it, but we're not using the information from it a whole lot. The solutions are running, but we're not enforcing the results from them and, therefore, our developers aren't driven to make absolutely sure that they are going well. Hopefully, we'll get there soon.

So far, the information that we're getting out of both the Nexus Lifecycle and SonarQube tools is really great.

And the integration of Lifecycle is really good with Jenkins and GitHub; those work very well. We've been able to get it to work seamlessly with them so that it runs on every build that we have. That part is easy to use and we're happy with that.

We're able to use Jenkins Pipeline and the integrations that are built into Gradle to incorporate that into our build process where we can have control over exactly when Nexus IQ and SonarQube analyses are run — what kinds of builds — and have them run automatically.

We've had it in place for about six months now.

Overall, the stability is pretty good. I haven't figured this out yet, but occasionally we do see failures in the Jenkins build. I haven't figured out why yet. I don't know if it's an issue with our Jenkins server or if it's with Sonatype. But otherwise, it seems pretty stable.

We haven't looked at its scalability at this point. We do have plans to use it more in the future, enforcing the results of the analysis to fail builds and force the developers to fix the issues in there before moving on.

We've used Sonatype's technical support a few times. We had some issues, and I think we might still have some issues, where the Sonatype Nexus Repository has integrations with IQ and SonarQube. We're getting some errors on the UI, so we've had Sonatype look into that a little bit. 

But they were responsive and had good suggestions, things to try. Overall, they're good.

We didn't have a previous solution.

The initial setup was pretty straightforward. The documentation is done well. It was easy to follow and I was able to set it up and get it working without a lot of effort.

I probably spent a day getting it installed, understanding it, and figuring out how to integrate it with our current solution.

In addition to myself, about 10 developers will eventually be looking at it to give them feedback on code quality and dependency management.

In terms of deployment and maintenance, it's me and a little bit of our CTO. He did the installation initially on our server and then I set up the integration with the rest of our process.

So far, it seems to be a good solution and there is a lot of very valuable information that the analysis provides.

The solution is mainly providing security, as well as creating threshold values. In terms of dependencies, it helps us with which ones are used and which are not, which need to be kept, which do not need to be kept.

We have reduced a lot of security access issues. For example, we can restrict user access level for the baseline of our organization's security.

Right now we are using it in Jenkins, it's open-source and it has very good restrictive policies. We are now moving into Bamboo. It has not been completely implemented in production, but we have started on it.

• Easy to handle and easy to configure
• User-friendly 
• Easy to map and easy to integrate 
• Easy to update 
• Fulfills a lot of security purposes

It has all the features we need.

The only thing I can say is that sometimes we face difficulties with Maven Central. We are integrating everything with that, as a repository. If Maven Central changes something in its versions... For example, if I'm using the 1.0.0 version, after one or two years, the 1.0.0 version will be gone from Maven Central but our team will still be using that 1.0.0 version to build. When they do builds, it won't build completely because that version is gone from Maven Central. There is a difference in our Sonatype Maven Central. That is the only issue I have seen so far. If an old version is gone, it's not able to use it anymore. Is there any way we can keep the old versions in our local repository instead of in Maven Central?

The stability is great.

I would rate the scalability at eight out of ten.

It's easy to solve issues and their support team is very helpful when I need help. They are able to give us solutions just like that, with a quick response. That is the beauty of their team. I like it. I rate technical support at nine out of ten. It's awesome the way they explain things to us, the way they email and send documentation.

We are looking back almost five years. We used a lot of IBM products and we used in-house products. With them, we were able to directly copy the dependencies we had in Maven Central to our local repositories.

We always us global setups. We use settings from XML files and we configure all of our repositories at a single, global repository in Nexus. We can just reference that URL and Nexus will report to our second XML file. That way, all the developers can use the same second XML file for extracting the different names or uploading the new Nexus stuff.

The deployment was very quick, it only took two or three minutes.

The licensing is okay. Compared to IBM, Sonatype is good.

There are demo licenses so ask them for one to try the solution. They will get back to you for sure. I would tell others how easy and how good the product is, and how easily they can implement, integrate it, and secure it. I refer this product to most of my colleagues and friends.

We integrated with Nexus IQ. The Sonatype people visited us three or four times. They explained to us how to use it, how Sonatype works, as well as the best features. They explained everything briefly and gave me the best examples and features and comparisons with other companies; how they're using it and how we could improve our organization. I liked that.

We have about 300 developers using it in our organization and they just use our global configuration files. They don't know what is going on in the background, it's completely infrastructure-driven. We used to give them instructions on how to use Nexus and how to check their security levels. Staff for deployment and maintenance includes six people in our team. Two are in the US and four are offshore in India. It's a 24/7 process so we need to cover everything.

We do have plans to increase usage, but that's not my role.

The solution is awesome, the way they have implemented it, the way they help us know what is good. We haven't found any difficulties.

Overall, I give the solution a nine out of ten. It's a very user-friendly product and it is very easy to integrate with any other products. It's more reliable and more securable.

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.