IT Central Station is now PeerSpot: Here's why

Sonatype Nexus Lifecycle OverviewUNIXBusinessApplication

Sonatype Nexus Lifecycle is #2 ranked solution in top Software Composition Analysis (SCA) tools and #4 ranked solution in application security tools. PeerSpot users give Sonatype Nexus Lifecycle an average rating of 8 out of 10. Sonatype Nexus Lifecycle is most commonly compared to SonarQube: Sonatype Nexus Lifecycle vs SonarQube. Sonatype Nexus Lifecycle is popular among the large enterprise segment, accounting for 74% of users researching this solution on PeerSpot. The top industry researching this solution are professionals from a computer software company, accounting for 24% of all views.
Sonatype Nexus Lifecycle Buyer's Guide

Download the Sonatype Nexus Lifecycle Buyer's Guide including reviews and more. Updated: June 2022

What is Sonatype Nexus Lifecycle?

Sonatype Nexus Lifecycle is an open-source security and dependency management software that uses only one tool to automatically find open-source vulnerabilities at every stage of the System Development Life Cycle (SDLC). Users can now minimize security vulnerabilities, permitting organizations to enhance development workflow. Sonatype Nexus Lifecycle gives the user complete control over their software supply chain, allowing them to regain wasted time fighting risks in the SDLC. In addition, this software unifies the ability to define rules, actions, and policies that work best for your organizations and teams.

Sonatype Nexus Lifecycle allows users to help their teams discover threats before an attack has the chance to take place by examining a database of known vulnerabilities. With continuous monitoring at every stage of the development life cycle, Sonatype Nexus Lifecycle enables teams to build secure software. The solution allows users to utilize a complete automated solution within their existing workflows. Once a potential threat is identified, the solution’s policies will automatically rectify it.

Benefits of Open-source Security Monitoring

As cybersecurity attacks are on the rise, organizations are at constant risk for data breaches. Managing your software supply chain gets trickier as your organization grows, leaving many vulnerabilities exposed. With easily accessible source code that can be modified and shared freely, open-source monitoring gives users complete transparency. A community of professionals can inspect open-source code to ensure fewer bugs, and any open-source dependency vulnerability will be detected and fixed rapidly. Users can use open-source security monitoring to avoid attacks through automatic detection of potential threats and rectification immediately and automatically.

Reviews from Real Users

Sonatype Nexus Lifecycle software receives high praise from users for many reasons. Among them are the abilities to identify and rectify vulnerabilities at every stage of the SDLC, help with open-source governance, and minimize risk.

Michael E., senior enterprise architect at MIB Group, says "Some of the more profound features include the REST APIs. We tend to make use of those a lot. They also have a plugin for our CI/CD.”

R.S., senior architect at a insurance company, notes “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.”

"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," says Subham S., engineering tools and platform manager at BT - British Telecom.

Sonatype Nexus Lifecycle was previously known as Nexus Lifecycle.

Sonatype Nexus Lifecycle Customers

Genome.One, Blackboard, Crediterform, Crosskey, Intuit, Progress Software, Qualys, Liberty Mutual Insurance

Sonatype Nexus Lifecycle Video

Sonatype Nexus Lifecycle Pricing Advice

What users are saying about Sonatype Nexus Lifecycle pricing:
  • "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."
  • "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."
  • "Cost is a drawback. It's somewhat costly."
  • "Lifecycle, to the best of my recollection, had the best pricing compared with other solutions."
  • "There are additional costs in commercial offerings for add-ons such as Nexus Container or IDE Advanced Toolkit. They come with additional fees or licenses."
  • Sonatype Nexus Lifecycle Reviews

    Filter by:
    Filter Reviews
    Industry
    Loading...
    Filter Unavailable
    Company Size
    Loading...
    Filter Unavailable
    Job Level
    Loading...
    Filter Unavailable
    Rating
    Loading...
    Filter Unavailable
    Considered
    Loading...
    Filter Unavailable
    Order by:
    Loading...
    • Date
    • Highest Rating
    • Lowest Rating
    • Review Length
    Search:
    Showingreviews based on the current filters. Reset all filters
    Senior Architect at a insurance company with 1,001-5,000 employees
    Real User
    Top 20
    Helps us drive down our technical debt due to components with known issues
    Pros and Cons
    • "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."
    • "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."

    What is our primary use case?

    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.

    How has it helped my organization?

    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.

    What is most valuable?

    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.

    What needs improvement?

    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.
    Buyer's Guide
    Sonatype Nexus Lifecycle
    June 2022
    Learn what your peers think about Sonatype Nexus Lifecycle. Get advice and tips from experienced pros sharing their opinions. Updated: June 2022.
    608,010 professionals have used our research since 2012.

    For how long have I used the solution?

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

    What do I think about the stability of the solution?

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

    What do I think about the scalability of the solution?

    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.

    How are customer service and support?

    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.

    Which solution did I use previously and why did I switch?

    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.

    How was the initial setup?

    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.

    What was our ROI?

    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.

    What's my experience with pricing, setup cost, and licensing?

    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.

    Which other solutions did I evaluate?

    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.

    What other advice do I have?

    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.

    Which deployment model are you using for this solution?

    On-premises
    Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
    Shubham Shrivastava - PeerSpot reviewer
    Engineering Tools and Platform Manager at BT - British Telecom
    Real User
    Top 20
    Integrates easily and finds all vulnerabilities and categorizes them pretty nicely
    Pros and Cons
    • "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."
    • "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."

    What is our primary use case?

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

    How has it helped my organization?

    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. 

    What is most valuable?

    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. 

    What needs improvement?

    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.

    For how long have I used the solution?

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

    What do I think about the stability of the solution?

    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.

    What do I think about the scalability of the solution?

    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.

    How are customer service and technical support?

    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.

    How was the initial setup?

    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.

    What was our ROI?

    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.

    What's my experience with pricing, setup cost, and licensing?

    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.

    Which other solutions did I evaluate?

    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.

    What other advice do I have?

    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. 

    Which deployment model are you using for this solution?

    On-premises
    Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
    Buyer's Guide
    Sonatype Nexus Lifecycle
    June 2022
    Learn what your peers think about Sonatype Nexus Lifecycle. Get advice and tips from experienced pros sharing their opinions. Updated: June 2022.
    608,010 professionals have used our research since 2012.
    Austin Bradley - PeerSpot reviewer
    Enterprise Infrastrcture Architect at Qrypt
    Real User
    Top 10
    Has brought open-source intelligence and policy enforcement across our software development life cycle for almost all of our applications
    Pros and Cons
    • "When I started to install the Nexus products and started to integrate them into our development cycle, it helped us construct or fill out our development process in general. The build stage is a really good template for us and it helped establish a structure that we could build our whole continuous integration and development process around. Now our git repos are tagged for different build stages data, staging, and for release. That aligns with the Nexus Lifecycle build stages."
    • "They're working on the high-quality data with Conan. For Conan applications, when it was first deployed to Nexus IQ, it would scan one file type for dependencies. We don't use that method in Conan, we use another file type, which is an acceptable method in Conan, and they didn't have support for that other file type. I think they didn't even know about it because they aren't super familiar with Conan yet. I informed them that there's this other file type that they could scan for dependencies, and that's what they added functionality for."

    What is our primary use case?

    We have a few applications that we're developing that use several different languages. The first ones we did were Python and Yum Repository applications. Recently we've started scanning C and C++ applications that use Conan Package Manager. We will soon start doing node applications with NPM. Our use case is that we primarily rely on the IQ server to ensure we don't have open source dependencies in our applications that have security vulnerabilities, and to ensure that they're not using licenses our general counsel wants us to avoid using.

    How has it helped my organization?

    When I started to install the Nexus products and started to integrate them into our development cycle, it helped us construct or fill out our development process, in general. The build stages are a good template for us to help establish a structure that we could build our whole continuous integration and development process around. Now our git repos are tagged for different build stages that align with the Nexus Lifecycle build stages.

    Going to the Nexus product encouraged me to look for a package manager solution for our C and C++ development. My customer success engineer, Derek, recommended that we go to one that Sonatype was considering integrating with the product, which was called Conan Package Manager. I started doing research with Conan and realized how beneficial it would be for our C and C++ development cycle. Transitioning to that has really changed our whole C and C++ development. It was because we needed to have Nexus scanning for our C applications and I needed Conan to do that.

    It's because of Conan that we've reduced our build timelines from weeks because we have so many architectures that we build for. After we figured out how to use it, we can build everything with only a couple of commands. Now, it's a really integrated process for our C and C++ applications, from development to the build pipelines to the IQ scanning, and the Nexus Repository manager repositories that we're using for building and packaging. It's been a fun process.

    In terms of the data quality, everything has been really good for our Python and our Yum repositories. I know that they are still building their capability for the Conan repositories, the C dependencies. Right now, what Derek has told me, is that Conan application are analyzed with what they call Low Quality Assessment, or LQA. Essentially, any package that has identified vulnerabilities will show up, otherwise, there's not much information on the package. So scanning for Conan is not as good as Python right now, but I know they're working on higher quality data for Conan packages.

    Comparing LQA in Conan to something like the higher quality data available in Python repositories does show a difference. For example, Nexus IQ identified a vulnerability in a Python package that we don't use, but it's a transitive dependency in four packages that we do use. We discovered the root vulnerability causing the problem in our four packages with the higher quality data, but we may not have been to do that as easily with a vulnerability identified in multiple C packages without the higher quality data. I'm not sure.

    Nexus will block undesirable open source components from entering our development life cycle. We've agreed on the governance of our policies for blocking builds automatically and we've set a date, for example, to start failing builds automatically on July 15.

    It integrates very well with our existing DevOps tools. The Azure DevOps Nexus IQ plugin was really easy. All we did was go to our DevOps portal, go to the add-ins, and then search the list for Nexus. We just clicked on it and it installed in DevOps. There are a couple of help pages on Sonatype's webpage, and I send those to the developers, they add the IQ plugin to the build pipeline and it just works. It's really nice also because the IQ plugin for DevOps gets updated before I can even go check on it. They've released two updates since we installed it. Every time I hear from Derek that they've updated the IQ plugin, I go to the IQ plugin page on our DevOps server, and it's already been updated. It's totally seamless for us.

    It has brought open-source intelligence and policy enforcement across our software development life cycle for almost all of our applications. We're still integrating it with all of our applications, but it definitely has brought the kind of intelligence that we needed.

    What is most valuable?

    Part of our use case is that we use Azure DevOps, so we have continuous integration, continuous deployment pipelines in Azure DevOps. The Nexus plugin for DevOps allows us to just include the IQ scan as part of the pipeline deployment. It's very seamless for our users. They don't even have to think about it until they have a violation. IQ informs them or stops the build, and the developers have to resolve it. 

    The default policies were very good for us. We're using all of the default ones except for setting the warning and the stop features at different build stages. It definitely provides the flexibility we need.

    We're not at the point in our deployment of the software to where we're doing automated git pulls and where it will automatically resolve vulnerabilities by downloading new packages. We haven't done that, but the integration with our Azure DevOps pipeline has been very seamless. I don't know of any developers that are using the integration with visual studio IDE.

    What needs improvement?

    The thing that they're already addressing is high-quality data for the Conan dependencies. They're very responsive to user needs. We're one of the first organizations to use Conan, so I identified a discrepancy in how they were scanning the dependencies, and they added the functionality within four weeks or so. The team is incredible. I can't think of any other ways that it could improve it.

    When Conan support was first added to Nexus IQ, it would only scan one file type for dependencies. We don't use that specific method in Conan, but rather, another acceptable method for declaring dependencies that IQ wasn't scanning. I think the Sonatype developers  didn't even know about it because they learning Conan as much as we were. I informed them of the other file type for declaring dependencies and they quickly added the functionality.

    For how long have I used the solution?

    I started installing it at the beginning of this year.

    What do I think about the stability of the solution?

    I've never had any problems with it, so it's been very stable.

    What do I think about the scalability of the solution?

    I don't know about the scalability yet because we are small and we don't have that many applications or packages yet. I haven't had to scale it. I designed, from the beginning, the storage architecture of my Repository Manager to be scalable because I knew a lot of the large data will sit there. I designed that upfront to be scalable to other storage volumes or even other servers. I know there are features for having multiple IQ servers or Repository manager servers and load balancing or having automatic failover and things, but I haven't done those things yet.

    How are customer service and technical support?

    Technical support has been great. I've never had any problems. When I do have an issue, sometimes I'll email Derek or I talk to him about it during our weekly meetings. He'll send off an email or a chat right away and get an answer back quickly about a resolution or resolution timeline.

    Which solution did I use previously and why did I switch?

    We weren't doing automated vulnerability scans or license scanning. We were pulling straight from the public repositories so everybody had local caches of varying packages, which was different from the repositories of packages on our build servers. It was like the Wild West, but the Nexus products have helped us consolidate our repositories.

    The primary reason why our senior director of product management decided he wanted to do this was that we develop sensitive software and need to ensure we don't have vulnerabilities from third party open source packages. We needed an automated way to do scanning instead of having the developers look at a list of their packages and compare them to a list of new vulnerabilities themselves. That would've been a nightmare. That central repository management was a secondary reason, but it was also important.

    As important as vulnerability scanning, the licensing was essential to us too because around the time we were evaluating the Nexus product, there was a large company that was getting sued for violating open source GPL-2 license requirements. We wanted to avoid problems like that. Those are the two primary reasons.

    How was the initial setup?

    The initial setup was easy. We're hosting on-prem and I put Nexus IQ on a VM I created according to Sonatype's recommended specs. It was really easy to install and it's really easy to update. The only thing that took a little longer to do was settings up HTTPS. It was my own fault because I had typos in configuration files that I'd overlooked. Following their instructions makes installation and upgrading really straightforward.

    I did the IQ server and the repository manager server at the same time, and it took around less than a day for both of them.

    When I first installed the two servers, I followed their recommended system requirements guidelines. In hindsight, because we are so small and we don't yet have that many applications, I probably could have started with IQ and Repository manager as containers. That would be okay for smaller companies that might be restricted on what resources they have available for hosting the servers. They could probably do containers in the beginning and then expand if they needed to later.

    The deployment was given to me as a project. I didn't have an implementation strategy when I started building the servers, but Derek and I created implementation strategies as we went, after I installed the servers.

    Initially after installing IQ and I putting some Python applications into, we had all of our policies set to warn and not fail builds automatically because we hadn't decided our governance process. That was part of the implementation strategy that we had to figure out. We had to decide a time to roll out our test applications and test groups. Derek was really instrumental in helping me see it in stages. We would test with the Python applications and then move on to other types of repositories and other types of applications for a broader adoption strategy.

    What was our ROI?

    Since the developers weren't doing really thorough vulnerability assessments in the past, I can only estimate how many hours it's saved and allowed them to continue developing the applications.

    For example, if one of our pipeline applications has 15 dependencies and a developer had to look for vulnerabilities in that list of 15 dependencies, it could take a half-hour every day for one application. If they're developing six applications at once, then it could be a couple of hours a day per developer. It would quickly get out of hand.

    What's my experience with pricing, setup cost, and licensing?

    I don't know anything about the pricing. I know that our license is the most encompassing one you can get. It includes the IQ server (Lifecyle, Firewall) and the Repository Manager Pro. Firewall is really useful for us to keep an eye on our proxy repositories for vulnerabilities. That's another layer of helping us make sure that we don't have vulnerable products. The expense is justifiable because of the potential to save a company a lot of money in lawsuits and risks from having vulnerable packages in their applications.

    What other advice do I have?

    I don't have any reason to rate it less than 10 out of ten. It's been really solid, really helpful, and it will pay off hugely as we continue to expand.

    Which deployment model are you using for this solution?

    On-premises
    Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
    Application Security at a comms service provider with 1,001-5,000 employees
    Real User
    Top 10
    Gets our developers to think about the third-party libraries they're pulling into the system, in terms of security
    Pros and Cons
    • "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."
    • "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."

    What is our primary use case?

    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.

    How has it helped my organization?

    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.

    What is most valuable?

    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.

    What needs improvement?

    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.

    For how long have I used the solution?

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

    What do I think about the stability of the solution?

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

    What do I think about the scalability of the solution?

    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.

    How are customer service and technical support?

    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.

    Which solution did I use previously and why did I switch?

    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.

    How was the initial setup?

    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.

    What was our ROI?

    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.

    What's my experience with pricing, setup cost, and licensing?

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

    What other advice do I have?

    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.

    Which deployment model are you using for this solution?

    On-premises
    Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
    Finto Thomas - PeerSpot reviewer
    Information Security Program Preparer / Architect at Alef Education
    Real User
    Top 20
    Gives our teams visibility into copyright and security risks in our code
    Pros and Cons
    • "The value I get from IQ Server is that I get information on real business risks. Is something compliant, are we using the proper license?"
    • "Nexus Lifecycle is multiple products. One drawback I've noticed is that there are some differences in the features between the products within Lifecycle. They need to maintain the same structure, but there are some slight differences."

    What is our primary use case?

    We are in the education industry, but we are a developer-based company. We heavily use lots of public libraries. We use Sonatype Nexus Lifecycle mainly for protecting us from vulnerabilities and license copyright issues. We heavily depend on its database.

    It's a hybrid. We have our on-premises instance for our internal security. With Sonatype itself, we use the cloud service, but we have a few modules on-premises, such as IQ Server and the report server. We have deployed those modules on AWS. As a company, we use cloud services 100 percent.

    How has it helped my organization?

    We have started rolling out to each of our feature teams and so far we have rolled it out to about 30 percent, but we can already see the benefit. It gives our teams easy visibility into the risk inside our code. "Risk" in this case can be copyright, more along the lines of compliance, and security itself, such as vulnerabilities.

    From the legal and security perspectives, we have a huge concern about what we use in our product and our platform. Before using Sonatype we had a huge business risk. Since bringing in Sonatype, we have visibility for both the legal and security teams. It enables us to maintain the quality from the third-party libraries.

    We follow the CI/CD methodology and Sonatype's impact is really huge because we are able to meet our continuous integration in the DevOps pipeline. The speed of that flow is noticeable. The impact is on both development and operations, together. The integration with the CI/CD pipeline is easy.

    What is most valuable?

    From the integration perspective, it is easy to use, out-of-the-box. The GUI is not complex.

    I mainly use two modules, the report server and IQ Server. The value I get from IQ Server is that I get information on real business risks. Is something compliant, are we using the proper license?

    With IQ Server we are currently running the default policy. We started deploying six months back and our main objectives were identifying any bad licenses in our library or product, and whether we are using any critically vulnerable assets. We have stuck with the default policies and they are giving us huge visibility and, as a result, we are putting a lot of effort into remediation.

    In terms of the data quality and the database they have for open source, I'm impressed. For our requirements, the data we get seems to be updated well when it comes to license-type and vulnerabilities.

    The solution also blocks undesirable open source components from entering our development lifecycle. We use it for controlling third-party libraries.

    What needs improvement?

    Nexus Lifecycle is multiple products. One drawback I've noticed is that there are some differences in the features between the products within Lifecycle. They need to maintain the same structure, but there are some slight differences.

    Other than that, the tool is very user-friendly and gives the right reports to the right teams.

    For how long have I used the solution?

    We have been using Sonatype Nexus Lifecycle for about the last six months.

    What do I think about the stability of the solution?

    Until now, we haven't faced any challenges on the stability front. If there's a challenge, if something is down, we definitely get a direct alert. We are happy with the stability part. Both the software and the infrastructure are good.

    What do I think about the scalability of the solution?

    There are two aspects to the solution's scalability. The infrastructure scalability is the first part, and that is good. The second part is the developer and the licensing front. When we started the program, we had 60 developers but we now have double that number. There's flexibility on both the infra and the licensing. That is good, as of now.

    How are customer service and technical support?

    When it comes to cultural adoption, when we put something new in the DevOps pipeline, the positive side is that we have a dedicated professional support team and there is a dedicated person. I'm on the security side, I'm not a developer. So the challenge for me is that when I go to the developers, they have a different language. That support person is always there to support me and I'm very happy with that support and the way they handle us as a customer. I can go to the development team or the department and say that, "If we need any support, let me know." I know that dedicated support person will be there for us. That's very much appreciated. That model is actually helping me to push our development teams to get into this new integration. The support model, with a dedicated person, is very useful.

    We have frequent meetings with the person who manages the team, and our dedicated support person from Sonatype. If there's a new update it's like we have permanent support. They help us to update.

    I would rate their support at nine out of 10.

    Which solution did I use previously and why did I switch?

    We were using Sonatype open source, the repository server, for a long time, as a free edition and as a PoC. That's why we picked Sonatype Nexus Lifecycle. 

    Before that, we were using a different solution for a period of time. We jumped to Sonatype from our previous solution because it had a limitation on the modules. If I go for a multiple module integration, there is additional cost, whereas with Sonatype, they bundle licenses. There's no limitation. I can go for any number of integrations. That's the reason we switched to Sonatype.

    How was the initial setup?

    The initial setup was triggered from a template in the cloud, so it was easily set up.

    With this implementation, the challenge is awareness. We have 14 development teams, but when we started the program there were 10. The number of development teams continues to increase and they use different tools and techniques in the CI/CD. From my side, in security, the idea is to make them aware. This would be the same whether the product was Sonatype or something else. Making them aware has been a very big challenge for me, to onboard them and make the product effective.

    So the initial, technical deployment is easy, but to make it effective, we have had to bring that awareness into focus and do repeated training.

    The initial deployment took one or two days, taking into account the infrastructure requirements in AWS. But that's not the issue. We deployed the server, but if nobody's using it there's no value from it. The value comes from being able to integrate all the developers. The dedicated support person was very useful in helping me create that awareness and value from it.

    We use a lot of tools in our CI/CD, so the initial month was more of a feasibility test and proof of concept which was validated with multiple scenarios. Then we started onboarding teams, one per month. We work with the Agile methodology in two-week sprints. Each team picked the integration per its own Agile sprint timeline, based on the product owner's priorities. Within the two-week sprint for a given team, we are able to do a full integration for that team. But within those two weeks, if you look at the real effort, it would be a maximum of about two days, including troubleshooting. We have covered 30 to 40 percent of our teams so far. Within the next three to four months we may be able to complete the process and cover 100 percent.

    What was our ROI?

    When I started with Sonatype six months back, I knew that I wanted to do 10 integrations. When I started integrating with a development team, and getting them more usability, I understood the reality was not 10, it was actually 100. When I ran with another vendor, even though I started with a small price, when I looked at the total cost of ownership or the return on investment, it was totally different. With Sonatype there is definitely a return on investment in the number of integrations and the personal support. In that sense, there has been a lot of value. 

    In addition, the bundled licensing is a huge difference and provides flexibility. We are not limited by the number of integrations, like in other products. We have flexibility and scalability. For us, the return of investment or value is huge, when it comes to the licensing model.

    What's my experience with pricing, setup cost, and licensing?

    Cost is a drawback. It's somewhat costly.

    Which other solutions did I evaluate?

    As part of the procurement process in Alef, we have to do a minimum three-product evaluation. We evaluated Sonatype, a different solution, and there were two more in the pipeline. Based on that evaluation, technical and other, Sonatype came into the picture. 

    The competing solution was actually cheaper, no doubt, but when we looked at the overall picture, the total cost of ownership after one year of integration, we understood it would be less with Sonatype, even though the initial price was less with the other products.

    If you're going to be scaling and growing quickly, in a way you cannot predict, the Sonatype licensing model and feature set are definitely good.

    What other advice do I have?

    Look at the scenario of the total cost after one year, not the initial stage. When we looked into the initial stage costs, there were vendors that cost less. But when you come to the integrations and real scenarios, that bill goes up. We had to clearly evaluate, not only the initial moment, but one year or two years down the line and consider the total cost of ownership.

    Also, be sure to properly utilize the engineer allocated to your site to help support the developers.

    Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
    Computer Architecture Specialist at a energy/utilities company with 10,001+ employees
    Real User
    Top 10
    Before using Lifecycle we were almost blind to the vulnerabilities in open source libraries
    Pros and Cons
    • "The scanning capability is its most valuable feature, discovering vulnerable open source libraries."
    • "The reporting capability is good but I wish it was better. I sent the request to support and they raised it as an enhancement within the system. An example is filtering by version. If I have a framework that is used in all applications, but version 1 is used in 50 percent of them and version 2 in 25 percent, they will show as different libraries with different usage. But in reality, they're all using one framework."

    What is our primary use case?

    We use it to scan applications for open source libraries and to find libraries with a clean version for developers. If one version is vulnerable, they can switch to another version which is clean.

    Our situation is that we are running it as a pilot. Hopefully, this year we will be moving the environment into production. Delays happened due to some of our workforce being allocated to different organizations, and then we had the pandemic.

    It's deployed on-premise, on a virtual host.

    How has it helped my organization?

    We can automate the pipeline of CI/CD. For example, if a publication uses an open source library and it's vulnerable, then the security team will mark it in the Lifecycle suite and it can go through the pipeline without manual interaction by the developer.

    I'm not a security guy but I have sat with the security team. Once you set the policies, you wont need to change them. The policies wouldn't change that frequently. It covers the needs that we have.

    Using the solution we have been able to clean our environment, providing more protection for our applications. We have a more hygienic environment than before. Before using Lifecycle we were almost blind to whatever we had and didn't look into the vulnerabilities within open source libraries. Now we do.

    It has helped to increase our productivity a lot, especially with Nexus Repository Manager. It is way more agile. There is no comparison between our productivity before and now.

    In terms of the accuracy of the data from Sonatype, at first the teams were challenging whatever the solution provided, but they then verified with the vendor of the open source libraries or via the related community, and they realized that the data from Sonatype is something that is done carefully. It's accurate and valid data. We are now introducing a security layer for open source. Before, there was no security on open source and they did whatever they wanted but that is no longer the case. They have to fix things before deploying them. It helps them resolve issues. It works most of the time, but sometimes there are challenges for the developer in solving them.

    We also use the solution to automate open source governance and minimize risk with policies. Some of our developers, although not all of them, have their own Jenkins installed and they set rules and policies. They have integrated Jenkins with Lifecycle and, whenever they push into production, it verifies they are not violating any policies. Once everything is smooth, it goes into production. We haven't formalized that process yet.

    What is most valuable?

    It's a great tool. We have it connected live to the Sonatype database. Whenever there is a new vulnerability, it's discovered. We have early detection of any vulnerability in our open source library. The scanning capability is its most valuable feature, discovering vulnerable open source libraries.

    What needs improvement?

    The reporting capability is good but I wish it was better. I sent the request to support and they raised it as an enhancement within the system. An example is filtering by version. If I have a framework that is used in all applications, but version 1 is used in 50 percent of them and version 2 in 25 percent, they will show as different libraries with different usage. But in reality, they're all using one framework.

    For how long have I used the solution?

    This is my second year using Sonatype Nexus Lifecycle.

    What do I think about the stability of the solution?

    It's very stable. I don't recall ever seeing problems. The main concern would be data-disk corruption, but I haven't seen it, even though the server, due to patching, has been rebooted multiple times.

    What do I think about the scalability of the solution?

    When it comes to scalability, there's a limitation in terms of high-availability. Sonatype recommends you go with high-availability. However, you have to have an Active-Passive solution and we don't use a separate installation for each organization. I know there are ways you can install multiple instances for each organization and proxy between them. Because we are a single organization that uses one installation, we have to set it to Active-Passive and manually switch the Passive on and off.

    How are customer service and technical support?

    My experience with their technical support has been good, overall.

    The problem for us is that we work in a different time zone than they do and the workdays are different. We don't work on Friday and Saturday. If we send them something on Sunday, we don't hear until on Monday. If it is urgent they get back to us.

    Which solution did I use previously and why did I switch?

    We used OWASP Dependency-Check, but for only about five months. It needs maintenance. You have to maintain the database library manually, and install it on the developers' workstations. There are a lot of drawbacks with that solution.

    If we depend on OWASP Dependency-Check, it is a public vulnerability tool and it is not a good database, to be honest. If you have a library where one version is marked as vulnerable and you go to the community, the owner of the library says all versions are vulnerable. You would not see the vulnerability reflected regarding the versions. You would see it on one version and the others would be marked as clean. The team at Sonatype is doing a good job of maintaining this information very well.

    We were working with Repository Manager and the security team switched to a Nexus server to reduce the effort and eliminate duplication. We now also have one, unified solution to cover all the possibilities.

    How was the initial setup?

    The installation is straightforward in terms of the application itself. However, with our setup, with our environment and the restrictions we have, we had to do a lot of things. But that work was from our side, not from the application's side. 

    We did the installation within about two to three days. I was part of our support team at that time. Later on, I added enhancements on-the-go, such as certification. If I were to do the installation now, I would do it within an hour. It is the configuration that you have to get to know. Once you know it, that's it. When it's new to you, you have to take the time to read the documentation to understand what's going on and do things right.

    What about the implementation team?

    I only worked with the support from Sonatype and I was the only person in our organization involved in the installation. I am also the only one who runs this part of our environment, in terms of maintenance.

    What was our ROI?

    We expect to see ROI once we're using it fully in production.

    What's my experience with pricing, setup cost, and licensing?

    Lifecycle, to the best of my recollection, had the best pricing compared with other solutions.

    What other advice do I have?

    We ran into too many debates and there was this culture of "security is not mine" and someone else should have to deal with it. After using the solution, they realized this is not the case. Security vulnerabilities had to be addressed. I was a developer and I understood their complaints, but security is important and you have to go with it. The tool is there to automate and simplify your work and you should utilize it. It has been a very good experience.

    We are introducing Lifecycle and developers will be aware, with the IDE plugin, from the beginning, whether whatever libraries they are using are vulnerable or not. There should be no delays if they work with it from the beginning.

    It is used, or should be used, by all of our 120 developers. But in a group developing a given application, not everyone would commit to it and scan the application. One would do the scanning. But, overall, all of them should be directly or indirectly using it or depending on it.

    When we move it to production we will need to do a recertification of the users and find out who is not using it, who would use it, and who is shifting to other organizations. Then we will decide on the number.

    Which deployment model are you using for this solution?

    On-premises
    Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
    Product Owner Secure Coding at a financial services firm with 10,001+ employees
    Real User
    Top 20
    Improves the overall hygiene of the source code and is helpful for code security and remediation of issues
    Pros and Cons
    • "The quality or the profiles that you can set are most valuable. The remediation of issues that you can do and how the information is offered is also valuable."
    • "The user interface needs to be improved. It is slow for us. We use Nexus IQ mostly via APIs. We don't use the interface that much, but when we use it, certain areas are just unresponsive or very slow to load. So, performance-wise, the UI is not fast enough for us, but we don't use it that much anyway."

    What is our primary use case?

    We use it in the pipeline. So, software development is done in a pipeline in automated steps. One of those steps is Quality Assurance for which we use, amongst others, Sonatype, and this is done automatically. Based upon the outcome of this scan, the software product can proceed to the next step, or its blocks need to be rebuilt with updates.

    We are using Nexus IQ Server 114, and we're about to upgrade to 122.

    How has it helped my organization?

    It improves the overall hygiene of the source code. We have a lot of scans going on every day. They are in the thousands. If high critical vulnerabilities are detected, of course, that is good. It is already proving its value to us down the line because these vulnerabilities do not reach production.

    Data quality helps us solve problems faster. We get the info on what's vulnerable, and most of the time, we get advice for an upgraded version that can be implemented right away. That's very valuable.

    It brought open-source intelligence and policy enforcement across our SDLC. It is the tool that we use for open-source scanning and third-party dependency scanning. So, it brings a lot of value to us from that perspective. 50% of the code that we use is open-source. So, it is important to scan it for all kinds of vulnerabilities. It is very powerful, and it brings a lot of security to us. It can block undesirable open-source components from entering our development life-cycle.

    It secures the software supply chain because it scans the packages that we get from our vendors, but we don't use it to secure our pipelines or steps in the build process. The build process itself is not secured by Nexus IQ.

    It improves the overall health and security of the software supply chain. Anything that is detected can be blocked.

    What is most valuable?

    The quality or the profiles that you can set are most valuable. The remediation of issues that you can do and how the information is offered is also valuable.

    Its integration with our tool landscape is very valuable. It is the interaction with account management and technical consultants.

    The default policies and the policy engine are very good. Most of what we have is the default. It is also possible to create your own policies and custom rules, but we only do that for a handful of exceptions. We are very pleased with the default policies and settings. It provides us the flexibility we need because we can use it in our own customized settings. It is flexible enough for us to work with.

    What needs improvement?

    The user interface needs to be improved. It is slow for us. We use Nexus IQ mostly via APIs. We don't use the interface that much, but when we use it, certain areas are just unresponsive or very slow to load. So, performance-wise, the UI is not fast enough for us, but we don't use it that much anyway.

    For how long have I used the solution?

    I have been using this solution for about five years. It was being used prior to me engaging with it. So, it was already there.

    What do I think about the stability of the solution?

    It is very stable. There are no complaints. It is good in terms of availability.

    What do I think about the scalability of the solution?

    We don't need to scale it. At this moment, it is right-sized for us. So, I don't see any scalability going on right now. We do self-hosting on our own internal platform. The resources that are available are not scalable, so to say. They are right-sized.

    We have between 750 and 1,250 users. The developers are the biggest part. We also have our operations support team that deals with upgrades, patch management, installation, and the Infra stuff. There are about 10 people. They don't only work on Nexus IQ, of course, but that's part of their job. There is also the security team, which is my team. It has about 10 people. We use Nexus IQ for all kinds of security review activities. We also have five metrics people who use these tools to gather metrics. They also use Nexus IQ.

    How are customer service and technical support?

    I have contacted them, and I would rate them a seven out of 10. Like every big company that you contact for support, you can get people who are well aware of your situation or less aware. Depending on who you get at the support desk, you might get immediate feedback or the right answer, or you might be going back and forth to get the right information. You don't have a single contact person for all your support, so the quality can change based on who you talk to.

    Which solution did I use previously and why did I switch?

    Our company didn't use any other solution.

    How was the initial setup?

    We have a team of about 10 people for upgrading the tool, patching the tool, migrating XIQ from our own platform to a public cloud platform, and creating system rules and policies.

    What was our ROI?

    For Nexus IQ, I have not seen any research that has been done for ROI. I am aware of other tools but not Nexus IQ.

    What's my experience with pricing, setup cost, and licensing?

    There are additional costs in commercial offerings for add-ons such as Nexus Container or IDE Advanced Toolkit. They come with additional fees or licenses. 

    Which other solutions did I evaluate?

    We always explore other tools. For every tool that we have, we constantly look at what's available. Every couple of years, we do an evaluation to see if there are replacements that are better suited to our needs. Our requirements might change over time. Our entire circumstance might also change from being on-premise to a fully-cloud company, where we might need to fulfill different types of needs. So, of course, we explore what are the best options for us. We stayed with Nexus IQ because they're a pleasant company to work with, and they offer a good product. 

    What other advice do I have?

    I would advise making sure that your developers are aware of why you are going to scan the source codes for vulnerabilities. An awareness training or awareness program on open-source vulnerabilities goes hand in hand with implementing such a tool because the tool is there to enforce policies, etc. If your community developer knows how to build secure software and how to look at open-source, it will drastically reduce the findings in the tool and create a healthy software landscape. So, awareness of secure coding principles should accompany the installation of such a tool.

    Although we are very familiar with the concepts and the topics, we don't make use of integration with IDEs. We do not support automated pull requests yet. It would take time for us to implement, and there are other things that we are busy with. It would depend on how things proceed. We also don't use Nexus Container. 

    It has not improved the time to release secure apps to market. It has also not increased developer productivity. In the short term, it decreases developer productivity because they have to fix stuff that otherwise would go undetected. So, productivity is hampered if you are confronted with vulnerabilities that you need to fix. Therefore, being more secure in the short term doesn't make you more productive. If you are aware of why you need to look at certain things, it can bring productivity in the long term.

    The biggest lesson that we have learned from using Nexus IQ is that with open-source, so many things can go wrong. Most of the vulnerabilities that you have in your software are due to the bad usage of open-source components.

    I would rate this solution an eight out of 10.

    Which deployment model are you using for this solution?

    On-premises
    Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
    Katrin Schenker - PeerSpot reviewer
    Software Engineer at a manufacturing company with 10,001+ employees
    Real User
    Top 20
    Automated process for downloading open source libraries has significantly decreased developer workload
    Pros and Cons
    • "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. 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 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 would be good if Sonatype would check the status of annotations for .NET packages."

    What is our primary use case?

    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.

    How has it helped my organization?

    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. 

    What is most valuable?

    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.

    What needs improvement?

    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.

    For how long have I used the solution?

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

    What do I think about the stability of the solution?

    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.

    What do I think about the scalability of the solution?

    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.

    How are customer service and support?

    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.

    Which solution did I use previously and why did I switch?

    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.

    How was the initial setup?

    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.

    What was our ROI?

    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.

    What other advice do I have?

    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.

    Which deployment model are you using for this solution?

    On-premises
    Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
    Flag as inappropriate
    Buyer's Guide
    Download our free Sonatype Nexus Lifecycle Report and get advice and tips from experienced pros sharing their opinions.
    Updated: June 2022
    Buyer's Guide
    Download our free Sonatype Nexus Lifecycle Report and get advice and tips from experienced pros sharing their opinions.