Sonatype Lifecycle Reviews

We are using Sonatype Nexus Lifecycle within our company for scanning our products with the Jenkins pipeline.

The most important features of the Sonatype Nexus Lifecycle are the vulnerability reports.

Sonatype Nexus Lifecycle can improve the functionality. Some functionalities are missing from the UI that could be accessed using the API but they are not available. For example, seeing more than the 100 first reports or, seeing your comments when you process a waiver for a vulnerability or a violation. 

When you submit a waiver, you enter a comment, and when you need to access this comment, in the reports, you don't see it. This is a drawback.

I have been using Sonatype Nexus Lifecycle for a short time.

I would rate the stability of Sonatype Nexus Lifecycle a seven out of ten.

Sonatype Nexus Lifecycle 

We have approximately 200 users using Sonatype Nexus Lifecycle in my company using this solution. They are mostly developers and security personnel.

I rate the technical support from Sonatype Nexus Lifecycle a six out of ten.

I have not used another similar solution previously.

We have a team in our company that does the implementation of the Sonatype Nexus Lifecycle.

We might increase our usage of the solution in the future, or we might move to another solution because of the issues we have had with it.

I would recommend to others to test the functionalities of the Sonatype Nexus Lifecycle to see if it meets their use case needs.

I rate Sonatype Nexus Lifecycle an eight out of ten.

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

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

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

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

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

Specifically features that have been good include

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

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

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

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

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

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

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

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

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

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

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

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

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

Overall, tech support is good.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

We 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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

Cost is a drawback. It's somewhat costly.

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.

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.

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.

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.

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.

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.

I started installing it at the beginning of this year.

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

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.

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.

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.

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.

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.

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.

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Everything else has been really good.

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

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

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

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

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

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

We did not have a previous solution.

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

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

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

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

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

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

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

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

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

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

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

The Lifecycle product is for protection, and licensing vulnerabilities issues, in our build lifecycle.

Without it we didn't have any way to detect vulnerabilities except through reactive measures. It's allowed us to be proactive in our approach to vulnerability detection.

Sonatype has also brought open-source intelligence and policy enforcement across our SDLC. It enforces the SDLC contributors to only use the proper and allowed libraries at the proper and allowed time in the lifecycle of development. The solution blocks undesirable open-source components from entering our development lifecycle. That's its whole point and it does it very well.

We use the solution to automate open-source governance and minimize risk. With our leaders across our different organizations, we set policies that govern what types of libraries can be used and what types of licenses can be used. We set those as settings in the tool and the tool manages that throughout the lifecycle, automatically.

It's making things more secure, and it's making them higher in quality, and it's helping us to find things earlier. In those situations where we do find an issue, or there is an industry issue later, we have the ability to know its impact rapidly and remediate more rapidly.

Its core features are the most valuable:

• protection
• scanning
• detection
• notification of vulnerabilities.

It's important for us as an enterprise to continually and dynamically protect our software development from threats and vulnerabilities, and to do that as early in the cycle as possible.

Also, the onboarding process is pretty smooth and easy. We didn't feel like it was a huge problem at all. We were able to get in there and have it start scanning pretty rapidly.

The data quality is really good. They've got some of the best in the industry as far as that is concerned. As a result, it helps us to resolve problems faster. The visibility of the data, as well as their features that allow us to query and search - and even use it in the development IDE - allow us to remediate and find things faster.

The solution also integrated well with our existing DevOps tool. That was of critical importance to us. We built it directly into our continuous integration cycles and that's allowed us to catch things at build time, as well as stop vulnerabilities from moving downstream.

Overall, it's pretty good. The drill-through and search capabilities are pretty good, they're not horrible. 

As far as the relationship of, and ease of finding the relationships between, libraries and applications across the whole enterprise goes, it still does that. They could make that a little smoother, although right now it's still pretty good. It's taking an eight out of ten and asking it to be a ten.

We've been using Nexus Lifecycle for over a year.
We use the Nexus repository for a long time.

It's very stable. We have not had any issues with it.

They're really good with scalability. We have an implementation that spans production use plus a disaster recovery area. The synchronization between those two and the high-availability are awesome.

We're at 100 or 150 licenses, maybe more. Developers are the main role as well as DevOps. The plan is to use it across every single application where we do development. We have a lot of applications, on the order of 500.

We have plans to expand usage, as far as the user base and the number of teams utilizing it go. 

Tech support is really available and very helpful.

We did not have a solution with this type of capabilities. We had some type of Nexus product but we layered this on top. We didn't have that capability.

The initial setup was straightforward. There weren't a lot of manual steps involved. There wasn't a ton of configuration. It has very smart defaults. There's not a high level of subject matter expertise required in the setup of the software. 

As for the decisions that you need to make about your policies, there are smart people out there to give you a lot of industry standards. But there is still a lot of work you need to do to make decisions for your enterprise. It can't do that no matter what it is. What you are going to do with those settings and the findings from those settings, that's the hard part. You have to make decisions about what to do with the data that it provides for you. That's not the setup, per se. That's just getting it to be very meaningful in your enterprise.

Our deployment was an interrupt-driven process because we had other work to do also. It took a few days.

The strategy for deployment was to involve legal, development, info security, and DevOps together - the leadership - to understand the tool's capabilities; to understand the defaults and also to come up with a strategy to manage the outcomes, the findings. That group of leadership had to set those settings and automatically be part of SDLC. Along with that, we had to implement a process that ensured that the findings - the breaks and the vulnerabilities that are found - would be visible. Notifications had to be made so that someone can triage and deal with them.

Deployment and maintenance require half a person. It's a side role because there's nothing to do most of the time. It's something you do occasionally, so we don't have a role dedicated to it.

We deployed it ourselves. We worked with Sonatype a little bit but we didn't need much from them. They were available when we needed them, but it was pretty straightforward.

The solution has improved the time it takes us to release secure apps to market. I can't approximate how much, there are too many factors there to consider.

If you find a problem reactively without the tool, there's the remediation cost, versus the savings of finding it in the first place. It would be really hard for me to go back right now and say how many things we found and how often because it's happening very dynamically. Those findings are not anything I can measure right now.

Then there are the things that we found that we might not have remediated. Maybe they were just okay, they weren't high-ranking and they weren't low-ranking errors. Now, we can decide that because we found them really early that we're not going to take that risk. Whereas before, we might've taken the risk - or not even have seen the risk. So it's hard to measure that. 

It's not literally speeding up our release to market. It's helping us avoid reactive costs and maintenance to the cycles after the fact. If an industry vulnerability is found, we get that notification really early.

We have seen a return on our investment. In some cases, where we've needed to find out the footprint of a certain library across our enterprise, we've been able to do that research in seconds or minutes, rather than long, drawn-out processes with people and teams involved to hunt it down through source code and the like.

As far as spinning up councils and people saying, "What's our vulnerability footprint look like?" we've been able to answer those questions much quicker and remediate quicker with other tools. Those things alone will probably pay for it. The safety stuff pays for it on its own too.

We've more recently also been able to leverage it as a solid containers repository solution.

Pricing is decent. It's not horrible. It's middle-of-the-road, as far as our ranking goes. They're a little bit more but that's also because they provide more. They put more manpower and time into their research - the details on their findings and the way they bring those to the surface. They offer some more features that others don't have, so I understand why it's a little bit more.

They were pretty good with us on pricing, working through it.

We looked at Artifactory as well. We went with Sonatype because it is more comprehensive, it's a market leader, has a great feature set, and support is really good. It's a good team and company. They provide much more granular details, as well as assistance in the remediation and understanding of vulnerabilities, than their competition.

In the early stages of planning and design for rolling this out, ensure that you get all of your stakeholders involved; those who will have an input on the policy settings. Also, ensure you have a process and people involved to deal with the findings. Have that baked into your standard enterprise processes. Don't just turn it on and not know what to do with it.

We use the Nexus IQ Server. That is the only product that we use, though there are other affiliated products Sonatype offers which integrates with it. We use it to categorize and index all libraries used in our software. Every time that a new build is created in our CI server, Nexus IQ server will check exactly what libraries that we're using. It does this for our Java libraries, JavaScript, and other things that it finds. Then, it checks a number of things for each of those libraries. E.g., it checks the license that is being used in it. Sometimes with open source software, the license is a bit more restrictive than might be convenient for what you are doing. Maybe it doesn't allow you to make changes to the library. Or, it's free to use for nonprofits, but if you're using a product which does make a profit, then you might have to purchase a license. Therefore, it protects us from accidentally misusing open source software and is protection against legal issues.

A bigger, ongoing use case is security. Sonatype checks security vulnerabilities that come up for all these libraries. Oftentimes, as a developer, you add a library that you want to use, and then you might check for security issues. Sometimes a problem comes up after your product is already live. IQ Server checks all libraries that we're using for security issues, reporting these, and allowing us to go through and see them to determine, "Is this something that we can waive?" It might be a very specific use case which doesn't actually affect us or we might have to mitigate it. Also, if a vulnerability or security issue is found in libraries later, it will send out alerts and notifications if a library is being used in our production environment, letting us know there is an issue. This allows us to address it right away, then we can make the decision, "Do we want to do a hotfix to mitigate this? Or is it something that isn't an issue in our case because we're not using it in a way that exposes the vulnerability?" This gives us peace of mind that we will be notified when these types of things occur, so we can then respond to them. 

One of the things that it detected was a small library that we use to generate PDFs. It pointed out this needed a purchased license. We had already bought the license because we did have some people in-house who were aware of that. However, it's still one of those things where I can see this easily going wrong for companies who are younger and don't pay as much attention to this type of stuff.

When IQ Server finds a problem a Jira ticket is created and an email is sent out. Usually, one of our technical people will check it out right away to see if this is something that can be simply scheduled in the next sprint or if it's something big. If it is something big that affects us and needs to be addressed right away, I know that we would likely be able to address it almost immediately, either by doing an update of the library or mitigation. We should be able to start work on it almost immediately. In very severe cases, we should be able to do this in just a matter of hours. We should be able to update our environments after we get a notification that the problem exists.

We have had cases where we wanted to add certain libraries, but the Nexus IQ IDE plugin showed there were some security issues with this library. Instead of using it, we found an alternative right away. Because it is easy to have this information available, it saves us the hassle of having to refactor later.

Nexus IQ Server has made it easier to address company or legal policies when it comes to the libraries we use. Sometimes, as a developer, you don't think about the legal aspects of a free and open source software. While we were aware that you occasionally need to buy a license for something, we're also paranoid of falling victim to giant lawsuits because we overlooked something in the license. We did have some enforcement of this before using Nexus IQ Server, but it would be done periodically and sometimes long after implementation of a problematic library was already done. Now it's all categorized in one place and we can very easily check license issues ahead of time. The awareness was there before, but now we have a definite way that it's all completely indexed. Enforcement is now easier and nothing can slip through the cracks. Everything is checked and will be reviewed unless someone specifically says, "This license is okay and you can use it."

It triggered a review of everything that's used and their licenses, since there are so many different open source licenses. Someone does have to go through each license and actually check off on it, with IQ Server we were able to do that more easily. It provides an ease of mind that if anything really bad would pop up, then it would easily show us in the report that it's there.

Since we started using IQ Server we have received a number of alerts regarding newly discovered security vulnerabilities in libraries we use in production. When that happens we delve in to it almost immediately. Up until now all of them have turned out to be for specific use cases that didn't actually occur in production. Just as a precaution though, we still schedule tickets to have such libraries updated anyway, in case it's later discovered that there are additional use cases that would allow exploitation of the vulnerability in production.

IQ Server also checks the overall quality of library. Often as a developer, to solve a certain programming problem we do some research online and may find suggested open source libraries that would address what we need. However, we don't always check how old it is or how maintained it is, but that is another thing that IQ Server will point out. "This version (or the whole library) you are using is like five to six years old. Maybe it's time to check if there are alternatives which are better kept up." That's another useful thing for us.

We enjoy how it works together with other stuff that we have. We integrated it with Jira to keep track of things. We have it set up so it will generate tickets in Jira automatically when it finds something, then those can be added to our sprints.

The quality of data seems very thorough. It compiles data from a couple of different sources. Sonatype double checks the vulnerability itself. I've seen instances where there will be a message saying something like, "According to official sources, this only occurs in version 4.2 or later, but our research team indicates that the vulnerability also exists in versions 3.x." This shows IQ Server gives you more information than what we previously would find, unless we did a lot of research and happened to stumble on that piece of information. Busy developers will usually prefer to spend the majority of their time implementing features and fixing bugs to meet customer time lines rather than indefinitely research possible vulnerabilities in a library they want to use. The information that we're getting through IQ Server makes it all easily accessible, and it's also thorough and comes with steps and descriptions of when this issue occurs for specific use cases, so it allows our developers to not lose a lot of time on research.

One of the things that we specifically did ask for is support for transitive dependencies. Sometimes a dependency that we define in our POM file for a certain library will be dependent on other stuff and we will pull that stuff in, then you get a cascade of libraries that are pulled in. This caused confusing to us at first, because we would see a component that would have security ticket or security notification on it and wonder "Where is this coming in from?" Because when we checked what we defined as our dependencies it's not there. It didn't take us too long effort to realize that it was a transitive dependency pulled in by something else, but the question then remains "Which dependency is doing that?" This is the biggest thing that we have talked to Sonatype about. Even though we have found an way to see where transitive dependencies are coming from, it would be nice if this was visible through IQ Server as well.

Another issue is that, although Sonatype categorizes and indexes a lot of different repositories, it doesn't index every single repo in existence. One of the components we used switched where it came from, so a later version was actually coming from a different repository that Sonatype didn't index, as it was relatively smaller. They cover a large amount of available libraries, but they don't cover 100 percent of them. In this case, that component that was marked as an unknown component. When we get this kind of notification, we have to double check it. That is how we found out that these are components aren't covered by Sonatype yet. We have put in requests to have this particular repository added to the sources Sonatype indexes. It's something to be aware of if you use obscure repositories.

We set it up in July 2019. Therefore, we have been using it about seven or eight months.

The stability is good. We have never had an issue with it being unreachable. I've not noticed any downtime with it. 

The single issue and change that our administrator ran into was that after he setup the solution, it used a file database locally. After he switched it from running in the foreground to running as a service on a VM, we realized that the database was gone, it had somehow reset. He was able to find the previous file used as the database though and successfully migrated the data to Postgres. That was all the way in the start and we noticed the issue right away. After that, we've had no issues with it.

Our system administrator has not had any issues installing updates to IQ Server.

We haven't had any major security things that we had to fix last minute or on production, which is a good thing. However, we have had vulnerability issues come up. We were able to check them out and notice that they wouldn't affect us immediately because they applied to a specific use case which doesn't occur in our application. However, it does show that things come up. Security issues are found, and if we would've done a manual scan with our previous product/project, we may not have known that something happening on production or we would have found it a lot later. Whereas now, these things pop up right away. It has seemingly increased the overall stability and how fast we can respond to things.

We think about software issues in healthcare. We always want to be very careful of security things in this application because of HIPAA and patient privacy and vulnerabilities to applications from things like ransomware. We get questions about this stuff from potential clients about how we can protect ourselves. We have continuous monitoring of security vulnerabilities, which is very good advertisement for our company. This was not something we could say before because we'd have to do it manually. Sometimes, a few months would go by before we could run another scan.

We have a relatively small number of people using IQ Server, consisting mostly of a few developers and project managers. Under those conditions it is performing very well. We have plenty of room to grow with it. We don't have any huge plans to expand use of the solution because it's fulfilling our current needs.

We filed a ticket for some unknown components and got quick feedback. They gave us pointers on how to figure out what it is. One of the things that we were impressed with was that they wanted to do a review of how we were using it after a few months. I guess this is a problem with us technical people. We often don't like reading manuals and like to figure out how stuff works. I initially was skeptical, but I figured that if they were offering it we should do it.

They had us show them how we had set it up, then they had a number of pointers for how we could improve it. E.g., we weren't fully using the JIRA integration and notifications and they pointed that out. There were a few other things they pointed out as well, such as a list of things for us to double check, like whether all our Javascript libraries and open source Javascripts were indexed correctly. Double checking that is what actually triggered the unknown component notification because we weren't 100 percent sure what it was. They then talked us through how to handle those. I'm happy they reached out to do the review. A lot of times, after you buy a piece of software, you just cost the vendor money every hour that they spend on you. In this case, the review was offered and initiated by them. We really appreciated that and we have had good experiences with them as a company.

It has been fun to work with Sonatype. We have been happy with them as a company.

We were using a product before and weren't super happy with it. I found this solution through an Instagram ad. I don't even know how it popped up there, but it was an ad on Instagram that was from Sonatype about one of their free publications that you could get about issues in DevOps. After that, we talked as a team, decided to check it out, and that's how it happened. As annoyed as I've been by those Instagram ads, this one actually worked out very well for us. I guess for Sonatype too.

We used a different enterprise solution (Palamida/Flexera) previously which was a bit cumbersome to run. It would only check when we manually triggered it. Previously, because the scan was sort of deferred, you would find out a month or two later (or whenever you did the scan) that the library might have an issue. Then, we would have to find an alternative library. However by that time, you've already used it and have to refactor what you were doing before. A refactor like this will take time away from our developers and testers and also will require a redeploy. The process now is a lot smoother because the scan is done automatically and immediately after each build, so we get feedback right away.

Additionally, with the plugin for our IDE that Sonatype provides, we can check whether a library has security, quality, or licensing issues very easily. Which is nice because Googling for this stuff can be a bit cumbersome. By checking it before code is even committed, we save ourselves from getting notifications at all.

Nexus IQ Server integrates well with our other ecosystem. Palamida required us to run it locally, like physically, because they would send you the hard drives that had all the mappings on it. These were used to index the components our software is using. We had trouble trying to figure out how to keep it up to date because they would have to send this to us every couple of months or so. Whereas now, we're running IQ Server in AWS and it actually connects to Sonatype's own service for updates. These live updates are a huge improvement to what we were using before.

Releasing a new version of our application used to take between three to six months. What would happen is before we would release it, that's when we'd do a scan and see if there was anything that we needed to fix. We have had it where enough issues came up where we're like, "We need to decide should we still release this or continue trying to work out all these different issues, then release it?" This would push back the release by two to four weeks. Now, because it's a continuous process and we can evaluate new components early on, it doesn't mess with that timeline so much. We know what the status is already at this point. If something comes up, then we can address it right away instead of having to do it near the end. It has helped us to solidify timelines a bit. Because of it, we have not had a delay in a release due to unknown security issues that we found near the end of our version release cycle.

On June 26, we got our license key for it. It was a week or so to get the whole thing up and running, from getting license keys to telling our IT department to set up the VM and install it, and then logging in to configure it.

The initial installation was rather straightforward. It was easy for me because we have a system administrator who takes care of it. But he did not report having any problems installing it. He had to also set up a database, then figure out some of the networking stuff, as sometimes the connectivity with the cloud services behind a VPN gets a bit tricky. But all in all it was fairly straight forward to integrate it. Once in the same virtual network, our VMs, Bamboo service, and Jira talked to each other and didn't have any issues. Installing updates has been straightforward as well.

Obviously there's a learning process that starts when you first log in. But things are pretty easy to figure out. Besides that Sonatype's support has been very good. They showed us how to use it immediately after installation, and they followed up some time later to see how we've implemented using it. They had some very useful tips and pointers at that time too. We've been impressed by their user support.

We had a call with the Sonatype team and they talked us through the setup. Their assistance with it was really good. That may have mitigated any complications that we would've had. As far as I'm aware, even the installation of the application was easy.

The DevOps stuff is a combo between the system administrator and developers. After he does all the VM and networking setup, we do the configuration from within the application once it is ready. I did some of the integration with Bamboo, then another developer set up the integration with Jira. I'm sure there are plenty of people who have the skill set which covers all those things and would be able to do the deployment with just one person. 

All our system administration is done by a company called Infidati. We've been using them for a long time, about five to six years and our experience with them has been excellent. They are fully remote, my immediate boss is the only one who has met people from their company. We mostly communicate with them through their email ticketing system. They're an easy, wonderful company to work with that has great response times.

This product was cheaper than the one we were using, so that is a direct savings. Though, it's hard to estimate time saved.

There is definitely a lot less frustration with it, because we had some frustration earlier with the last product. Some of the frustration that we still have was trying to find an updated version of the library, which is not really Sonatype's fault. That is just how open source software works. However, there is definitely a lot less frustration with a lot more clarity about what exactly we're looking at and what the step is needed to get rid of the vulnerabilities that we do find. It's hard to measure the impact of reducing developers' frustration, but I think we can all agree that having happy developers is good for a company!

Another thing that's hard to measure is the positive impact on company image. We get security questionnaires from potential clients, which will ask how we detect and address security issues. In our industry, what is that worth to a health system that houses patient information that we continuously monitor for security vulnerabilities? And that we are able to address these concerns as soon as they come out? It's a marketing thing and it's hard to quantify what that's worth, but we know in healthcare these things are definitely valued and appreciated.

In addition to the license fee for IQ Server, you have to factor in some running costs. We use AWS, so we spun up an additional VM to run this. If the database is RDS that adds a little bit extra too. Of course someone could run it on a pre-existing VM or physical server to reduce costs. I should add that compared to the license fee, the running costs are so minimal they had no effect on our decision to use IQ Server.

The license fee may be a bit harder for startups to justify. But it will save you a headache later as well as peace of mind. Additionally, it shows your own customers that you value security stuff and will protect yourselves from any licensing issues, which is good marketing too.

We did not evaluate other options. Though, we did compare it to what we were using. When we looked at what Sonatype did and how it was able to run in the cloud, we were eager to give it a shot. We honestly didn't do extensive research into other alternatives. We knew we wanted to switch from what we were using rather quickly and Sonatype's response time was very good.

Do it as early as possible. You will have to clean up sooner or later. I remember when we fired it up it immediately found things that the last solution didn't find. This made sense after we realized that IQ Server gets continued updates and our last solution was just getting updates whenever we were able to get new hard drives sent to us. Our first scan popped up with a number of high vulnerability and security issues. At that time the Sonatype people were on a call with us to help us out setting it up. We asked them if seeing this many alerts was pretty average and they told us it was pretty normal in their experience. So that's when the cleanup started.

Our awareness of how many of these open source libraries have things that you got to watch out for has increased a lot. We would find some stuff out through our previous solution, but sometimes it was unclear exactly how serious it was, where it came from, or how to fix it. Additionally we've gotten a lot better at manual dependency resolution, because sometimes the problematic version of a component you're trying to eliminate is a transient dependency. so you have to figure out which alternative version you can use and then tell the top level dependency to use that instead.

None of our people who went to college to learn how to write software or do Java certification remembers ever getting a class on how to deal with these kind of things. Nobody remembers taking a class where they warn future developers: "You're going to have licensing issues that you will need to solve. You will need to do dependency resolution and be asked to mitigate security issues in this stuff as you use it." But this is actually a pretty important aspect of proper software development. Our team already had this awareness, but now it is now something we can also easily check. It is a continuous part of our sprints to check and handle notifications of these security issues. We've had to learn a lot more about how to fix transitive dependencies.

While we don't have integrations directly with our version control systems, we do integrate with our continuous integration service and ticketing system. We use a host of Atlassian products: Jira is one of them and Bamboo is another. You can use this solution to automate open source governance and minimize risk. E.g., we could have a build fail when it finds security issues, but we have not done that for our development and test environments as of yet. The solution also integrates with things like user directories.

We did look through the default policies. We also received some help from Sonatype to go over them. As a default, the security policies were good. Therefore, we decided to stick with them.

I would give the solution between an eight and nine (out of 10). If there was a way to easily see where a transient dependency is pulled in from, and if Sonatype would add a few more of the repositories that we pull dependencies from, then I'd probably give them a 10 (out of 10).

We are using the Nexus Repository Manager Pro as exactly that, as an artifact repository. We tend to store any artifact that our application teams build in the repository solution. We also use it for artifacts that we pull down from open-source libraries that we use and dependencies that come from Maven Central. We use it to proxy a few places, including JCenter. We also use it as a private Docker registry, so we have our Docker images there as well.

We're on version 3.19. We also have Nexus IQ server, which wraps up within it Nexus Firewall.

We have a lot of legacy applications here and they're all built with Ant scripts and their dependencies come from a shared folder. There's not a lot of "accountability" there. What we get out of using Nexus is that all of our dependencies are in the same place and we can specify a specific version. We no longer have a situation where somebody has pulled down a .jar file and stuck it in this folder and we don't know what the version is or where, exactly, it came from. That's one of the benefits.

Another of the main things we get is what Sonatype calls a "bill of materials." We can go into our Nexus product and say, "Okay, here is our ABC application. What are its dependencies?" And we can be specific down to the version. We know what's in it and, if a vulnerability gets reported, we can look and see if we use that particular component and in which applications, to know if we're vulnerable. If we find we're exposed to that vulnerability we know we need to go and remediate it.

The biggest benefit we get out of it is the overall ease of development. The ability to automate a lot of the build-and-deploy process comes from that.

The data quality helps us solve problems faster, as in the security vulnerability example I just mentioned. In those circumstances, we have to solve that problem. Previously, we wouldn't have seen that vulnerability without a painstaking process. Part of the Nexus product, the IQ Server, will continually scan our components and if a new CVE is reported, we get that update through Nexus IQ. It automatically tells us, "Hey, in this open-source library that you're using, a vulnerability was found, and you use it in these four applications." It immediately tells us we are exposed to risk and in which areas. That happens, not in near real-time, but very quickly, where before, there was a very painstaking process to try to find that out.

A year ago we didn't have DevOps tools. We started building them after I came on. But Nexus definitely integrates very well with our DevOps tools. Sonatype produces plugins for Jenkins to make it seamlessly interact, not only with the repo product, but with the Nexus IQ product that we own as well. When we build our pipelines, we don't have to go through an array of calls. Even their command-line is almost like pipeline APIs that you can call. It makes it very simple to say "Okay, upload to Nexus." Because Jenkins knows what Nexus is and where it is — since it's configured within the Jenkins system — we can just say, "Upload that to Nexus," and it happens behind the scenes very easily. Before, we would have to either have run Maven commands or run Gradle commands via the shell script to get that done. We don't need to do that sort of thing anymore.

The solution has also brought open-source intelligence and policy enforcement across our SDLC. We have defined policies about certain things at various levels, and what risks we're willing to expose ourselves to. If we're going to proxy a library from Maven Central for example, if the Nexus IQ product says it has a security-critical vulnerability or it's "security high" or it's "component unknown," we can set different actions to happen. We allow our developers to pull down pretty much anything. As they pull something down from say, Maven Central, it is scanned. If it says, "This has a critical vulnerability," we will warn the developer with the report that comes out: "This has a security-critical vulnerability. You're allowed to bring it down in development, but when you try to move to QA or staging, that warning about the 'security-critical' component will turn to a failure action." So as we move our artifacts through that process, there are different stages. When someone tries to move that component to our staging environment, it will say, "Oh no, you can't because of the security-critical thing that we've been warning you about. Now we have to fail you." That's where we get policy enforcement. Before, that was a very manual process where we'd have to go out and say, "Okay, this thing has these vulnerabilities, what do we do with it?" It's much more straightforward and the turnaround time is a whole lot faster.

Automating open-source governance and minimizing risk is exactly what Nexus is for. Our company is very security conscious because we're governed by a number of things including the Fair Credit Reporting Act, which is very stringent in terms of what we can and cannot have, and the level of security for data and information that we maintain. What Nexus does is it allows us to look at the level of risk that we have in an application that we have written and that we expose to the companies that subscribe to us. It's based on the components that we have in the application and what their vulnerabilities are. We can see that very clearly for any application we have. Suppose, all of a sudden, that a Zero-day vulnerability — which is really bad — is found in JAXB today. We can immediately look for that version in Nexus. We can see: Do we have that? Yes, we do. Are we using it? Yes, we are. What applications are we using it in? We can see it's in this and that application and we can turn one of our teams to it and get them to address it right away.

I don't know exactly how much time it has saved us in releasing secure apps to market, but it's considerable. I would estimate it saves us weeks to a month, or more, depending upon the scope of a project.

And it has definitely increased developer productivity. They spend a lot less time looking for components or libraries that they can download. There was a very manual process to go through, before Nexus, if they wanted to use a particular open-source library. They had to submit a request and it had to go through a bunch of reviews to make sure that it didn't have vulnerabilities in it, and then they could get a "yes" or "no" answer. That took a lot of time. Whereas now, we allow them to download it and start working with it while other teams — like our enterprise security team — look at the vulnerabilities associated with it. That team will say, "Yeah, we can live with that," or "No, you have to mitigate that," or "No, you can't use this at all." We find that out very much earlier in the process now.

It allows us to shift gears or shift directions. If we find a component that's so flawed that we don't even want to bring it into the organization from a security standpoint, we can pivot and say, "Okay, we'll use this other component. It doesn't do everything we needed, but it's much more solid."

I won't say there aren't a ton of features, but primarily we use it as an artifact repository. 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; we use Jenkins to do continuous integration, and it makes our pipeline build a lot more streamlined. It integrates with Jenkins very well.

The default policies and the policy engine provide the flexibility we need. The default policy was good enough for us. We didn't really mess with it. We left it alone because the default policy engine pretty much works for our use cases.

The integrations into developer tooling work just fine. We primarily use Gradle to build our applications. We just point the URL to what we call our "public repository group" in Nexus. It's a front for everything, so it can see all of the other underlying repositories. Our developers, in their Gradle builds, just point them to this public repository and they can pull down any dependency that they need. It doesn't really integrate with our IDE. It's just simply that we use Gradle and it makes it very straightforward.

Nexus blocks undesirable open-source components from entering our development lifecycle because of the IQ policy actions. We define what sort of level of risk we're willing to take. For example for "security-critical," we could just fail them across the board; we don't want anything that has a security-critical. That's something we define as a CVE security number of nine or 10. If it has a known vulnerability of nine or 10 we could even stop it from coming down from Maven Central; it's quarantined because it has a problem that we don't want to even introduce into our network. We've also created our own policy that we call an "architecture blacklist," which means we don't want certain components to be used from an architectural standpoint. For example, we don't want anybody to build anything with Struts 1. We put it on the architecture blacklist. If a component comes in and it has that tag, it fails immediately.

Some of the APIs are just REST APIs and I would like to see more of the functionality in the plugin side of the world. For example, with the RESTful API I can actually delete or move an artifact from one Nexus repository to another. I can't do that with the pipeline API, as of yet. I'd like to see a bit more functionality on that side.

I, personally, have used Nexus for a number of years. I have been with my current company, MIB, for just over a year. We brought it in just over a year ago right after I started.

I've had no trouble with it. We're currently running it even on a single server and we don't have many problems with it. It seems very easy to move into what we call a high-availability mode. Upgrades to a new version are done within a 30-minute timeframe, so we can easily schedule them.

Even though we don't employ it in a high-availability mode, looking at the documentation, it's very easy to scale out. You can put up multiple servers and point them at the same shared file system. Sonatype also has a cloud offering if you want to go completely hands-off. But it seems to scale very well. We haven't had to scale it yet, but it seems very straightforward to do so.

We talk with John Burke, our rep at Sonatype. He was originally our sales rep and now he's their regional sales director and we have a new sales rep. But we still keep in very close contact with John.

Sonatype also has a concept, a position called a success engineer. We have regular meetings every two weeks with a representative from Sonatype. We talk about our implementation, where we are, where we want to go, and how we can get to the point that we need to be at. We are still very engaged with them.

Technical support is great. But because we also have this customer success engineer, a lot of times if we have questions on how something works, we can ask him. While he's not a technical expert, he's a very good end-user person. He can say, if we need to change how a policy works or we want to do this or that, "Well here, you go in here and you do that." We get some ongoing customer support from that customer success engineer. 

We have only set up two technical support tickets with them and they've been pretty good about them. I have nothing bad to say about the technical support. They've stepped up when we have needed them to.

We weren't using anything prior to this.

Having set it up myself in previous companies, I know there are ways to set it up that are easy. You can just drop a .war file into a Tomcat container and you're set up. You then just have some configuration to deal with. 

We didn't do that. We set it up as a process on a host server and set it up with specific memory and a very specific file system for it. We had help with that from Sonatype. We had a Professional Services person here who set that up with us.

We were done in one day. From downloading the executable, to running it, to installing it, to having it set up and configured, it was done in a day, but again, we had Professional Services here for that day.

Our strategy was to implement the repository first. But we also added Nexus IQ. Sonatype has best practices for this and, while we were close to what they offered, we weren't exactly it. So both of those servers are on the same physical hardware. Sonatype recommends separating Repository and IQ Server on different servers, but we didn't do that. Our implementation isn't fast enough to really warrant that. We're a smaller shop so we don't really need that vastness of setup.

The person who came out to help us actually runs Sonatype's customer service center. We keep in very close contact with them.

In the productivity, and the turnaround time of producing new applications and updating old applications, the return on investment is that it takes much less time to add features or produce a new product out to our subscribers than it did before. That allows us, obviously, to start billing for those services sooner. Without Nexus, it would take a considerably greater amount of time. Our return on investment is based upon how many applications we bring out and the turnaround time of the development team.

I'm not involved in the financial aspects, but I don't think it's overly expensive. We use the professional version. There's an open-source version that would cost us next to nothing, but we do use the professional version.

We did look at Artifactory and one other solution when we were doing our due diligence before picking a product. We did a proof of concept for Artifactory, but we ended up choosing this one.

Nexus Repository is a very specific product. It does very specific things. It's an artifact repository. I would suggest, if you're starting out, to start out with the open-source version and see if it meets your day-to-day needs. If it does, as you start to use it your development teams come to rely on it and it becomes one of those things that if it were to go down, all of your development would stop. So it mandates you to look at the professional version so that you get some backend support from Sonatype in the case that something should happen to it.

Our company, as a whole, has about 150 employees, but not everybody uses it. There's a group repository that's open and anyone can go to it. You can pull down anything you want, anonymously. You don't even have to log in. But there are very few people — four Nexus admins — who can upload stuff. And on our continuous integration server, Jenkins, those four are the only users who can upload anything or push anything into the repository. Our developers don't push anything into the repository. They build some stuff, they check it into Source Control, and then the continuous integration engine sees that, picks it up, builds it, takes the artifacts, and puts them into Nexus. The lion's share of the users who use it are pulling stuff down from it to their desktops and into their IDEs. There are about 25 of those users. They use it to pull dependencies and other things and then they check it into a source code repo and Jenkins takes over from there and does the building and the deploying, etc.

For maintenance and deployment, we usually have a staff of two, although we currently have only one. I will back-fill that as needed. But there's really no maintenance that we have to do to, other than updating to newer versions from time to time.

I would rate it at about a nine out of 10. A perfect 10 comes from what I mentioned earlier. I would like to see a little bit more functionality from the CI plugin aspect. I'd like to be able to do more of what I can do with the REST APIs, in the plugin, so I could automate some of those tasks. But that's the only negative thing I have to say about it.

We're using it to change the way we do our open-source. We used to actually save our open-source and now we're moving towards a firewall approach where we are proxy to Maven repos or NPM repos, and we are using those proxies so that we can keep ourselves from pulling in known bad components at build time. We're able to be more proactive on our builds.

It's allowed our developers, instead of waiting till the last minute before a release, to know well ahead of time that the components are bad and they are able to proactively select different components that don't have a vulnerability or a licensing issue.

Also, the solution's data quality seems to be good. We haven't had any issues. We're definitely able to solve problems a lot faster and get answers to the developers a lot faster.

And Nexus Lifecycle integrates well with your existing DevOps tools. We were able to put it right into our build pipelines. We use Jenkins and we're able to stop the builds right in the actual build process whenever there's a quarantined item.

In addition, it has brought open-source intelligence and policy enforcement across our SDLC. It has totally changed the way we do our process. We have been able to speed up the approval process of OSS. Given the policies, we're able to say, "These are okay to use." We've been able to put in guardrails to allow development to move faster using the product. Our pipelines are automated and it is definitely a key component of our automation.

Finally, the developers like it because they're able to see and fix their issues right away. That has improved. For example, let's say a developer had to come to us and said, "Hey, scan this. I want to use it," and we scan it and it has a vulnerability. They've already asked us to do something that they could have done through the firewall product or Lifecycle. Suppose it takes us a day and then we turn around and say, "Okay, here are the results," and we say they can use this version of that product. They've got to download it and see if it works. So we're already saving a day there. But then let's say they have to send it off to security to get approval on something that security would probably approve anyways. It's just they didn't know security would approve it. They would have to wait two or three days for security to come back and give them an answer. So we're looking at possibly saving four days on a piece of code.

The proxy repository is probably the most valuable feature to us because it allows us to be more proactive in our builds. We're no longer tied to saving components to our repository.

The default policies are good, they're a good start. They're a great place to start when you are looking to build your own policies. We mostly use the default policies, perhaps with changes here and there. It's deceptively easy to understand. It definitely provides the flexibility we need. There's a lot more stuff that you can get into. It definitely requires training to properly use the policies.

We like the integrations into developer tooling. We use the Lifecycle piece for some of our developers and it integrates easily into Eclipse and into Visual Studio code. It's a good product for that.

It would be helpful if it had a more detailed view of what has been quarantined, for people who don't have Lifecycle licenses. Other than that, it's pretty good.

We've been using it for about a year now.

The stability has been great. We haven't had any issues in the year that we've had it running. So far, so good.

It's probably not that scalable in its current state. That has to do with the way that the applications are designed. I think they're working on that when they start working on the HA solutions. For Nexus and Nexus IQ I think that will change. But right now, it's not very scalable.

Sonatype's technical support for this solution has been great. They answer my questions, even my stupid questions. I might be asking them, "Hey, how do I do this? I can't find it." and they'll say "Oh, it's just this button right here." They never make me feel too bad about it.

We didn't have something that does what a firewall does. We used a different repository and used Nexus IQ to do the enforcement of policies by scanning OSS's individually. It's nice having it happen automatically on the repositories now.

The directions on the site are good. Once you follow those, you're good. But if you're looking to set it up by just clicking around, you will probably have a hard time figuring it out. But it's easy once you know what you're doing.

From inserting the license file to proxying my first repos, it took about an hour, at the most.

We were doing a conversion. So the implementation strategy, if we're just talking about firewall, was that we already had Nexus. We bought Nexus and the firewall at the same time. Once Nexus was installed and set up, it was a matter of importing our repositories from Artifactory Pro and then connecting the proxy repositories. I can't say there was any "super-strategy." It was just turning it on, getting it going, and then moving the developers over to it using their settings, XML, etc. And we had to set our NPM RC files to point to our new repository using the firewall and, for those repositories that have a firewall, they had to be turned on with them.

We did it ourselves.

We don't have any evidence that the solution improves the time it takes us to release secure apps to market because we haven't released an app yet, but I'm sure it will.

Just the dev happiness is already a type of ROI, in addition to how fast they're able to go using it.

We pay yearly.

I looked at a few others, like Black Duck, and I was not impressed by them. I didn't get a chance to actually use Black Duck but everything I read said that Black Duck came up with more false positives than Sonatype.

My advice would be to use it as soon as you can. Get it implemented into your environment as quickly as you can because it's going to help. Once you get it, get your devs on it because they're going to thank you for it.

All of our development is happening using the firewall. All our build pipelines are going through there. As far as licensed users go who can look at Nexus, we've got about 35. They range from devs to security personnel to DevOps people.

All our applications are moving over to it, so that's definitely going to increase the usage. We've got about another 200 applications on the board that will come into our greenfield process so they will be pulled straight into that repository using the firewall. It's definitely going to keep growing.

For deployment and maintenance of this solution there is really just our DevOps team of about four people, but I'm primarily responsible.

I would rate it a 10 out of 10. It does everything I need it to do.

Our primary use case is preventing major security vulnerabilities.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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