Sonatype Lifecycle Reviews

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

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

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

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

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

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

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

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

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

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

We didn't have a previous solution.

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

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

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

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

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

At the moment, we are primarily targeting security vulnerabilities, and only those with high severity. 

We have it configured not to block anything at this stage. We only aim for visibility at the moment. We might eventually start blocking or failing builds, but right now, we only want to have visibility.

We are still pretty early in our adoption phase. We are onboarding new applications much quicker than we are remediating issues in the existing ones.

For the application onboarding, we are focusing on automating that as much as possible. Considering the amount of applications that we scan, it's probably not feasible to do all that within the GUI, but the APIs provided by the solution are really good. We have some positive impressions for that. The automatic onboarding seems to work quite well.

One thing we recently did is we automatically onboarded every application that we deployed to production. We scanned each one of them and now have a complete picture of our estates. Every single vulnerability introduced from an open source component is now visible, and we have a clear number. That number was big. Really, we have a lot of issues which we were unaware of. We suspected that we had them, but we now have a clear number that makes selling the solution internally a lot easier.

The solution brought open source intelligence and policy enforcement to a small extent across our SDLC (software development lifecycle) because we have only fully rolled it out in a small number of teams. However, where we did do this, we have started scanning right at the built face, seeing issues really early in the lifecycle.

The solution automates open source governance and minimizes risk. We are trying to reduce the amount of vulnerabilities that we introduce using open source codes. The entire goal of why we're doing this solution is to have it in the lifecycle of our software development and reduce risk.

The key feature for Nexus Lifecycle is the proprietary data they have on vulnerabilities. The way that they combine all the different sources and also their own research into one concise article that clearly explains what the problem is. Most of the time, and even if you do notice that you have a problem, the public information available is pretty weak. So, if we want to assess if a problem applies to our product, it's really hard. We need to invest a lot of time digging into the problem. This work is basically done by Sonatype for us. The data that it delivers helps us with fixing or understanding the issue a lot quicker than without it.

The solution integrates well with our existing DevOps tools. We have a few different ways of integrating it. The primary point is the Jenkins plugin to integrate it into the pipeline, but we also use the API to feed applications from our self-developed systems. So, the Sonatype API is very valuable to us as well. We've also experimented with IDE plugins and some other features that all look very promising.

The GUI is simple, so it's easy to use. It started as great to use, but for larger scale companies, it also comes with some limitations. This is why we tried to move to more of an API approach. So, the GUI could use some improvements potentially.

Something else that's a bit lacking is most of our components are not explicitly included but are transitive dependencies. We have 50 applications that all report security issues, but they all come from one central library that we built ourselves, which is also scanned by Lifecycle. So, we have 51 components, and we are not seeing that only one of them is really the one we should be targeting. What would be really great in the solution would be some dependency graphing, or at least collecting the transitive dependencies. That would help for larger scale implementations.

The Success Metrics report is really focused on very specific numbers that are not interesting to us. They are for when you are much further along in the onboarding process. There is an API which allows you to retrieve the data on which the Success Metrics are based. We use this API to create our own charts, reflecting what we're looking for.

My company started its POC about two years ago. 

I only started at the company in September last year, so my experience only accounts for the last four months.

I think we have had zero downtime since I have been here. I didn't hear that there ever was an issue before, so it's been absolutely great.

Part of the deployment and maintenance is done by me. Upgrading the solution to a new level has only been done by one single person in the past, who spent three to four hours per upgrade on it. It's really low maintenance for us.

We have had absolutely no issues with scalability. We built it for a small PoC. We have now scaled it to scan our entire application landscape on the exact same hardware that it was sized on at the beginning and we have had zero issues. So, it's absolutely great.

The solution is only very limited in its current usage. Our current adoption rate is 10 percent. We plan to hopefully introduce it into every application that we build in a language that is supported by Nexus.

At the moment, we have 20 licensed users. These are primarily IT security managers (such as myself), developers, and product owners.

This technical support is very good and extremely quick. I have had two or three support cases and none of them took longer than a day to get a response. Sometimes, they respond, "No, the solution cannot do that. We have built it in that way and you need to raise a product improvement requests." So, it's not always what you hope to receive, but at least the answer is always clear and quick.

Most of the time, the data quality is very good. We have had some cases where there were some weird results or errors in it. But, when I contacted support, most of the time they managed to fix it or explain why it wasn't displayed in the way I was expecting.

The central IT service organization in our firm manages all our Linux setups and stuff like that. He primarily repackages the installer into an RPM for our Linux service. Usually, the upgrade is just totally painless and right off the books.

ROI on a security product is always hard to argue because you never know how expensive a security issue could become.

The price is good. We certainly get a lot more in return. However, it's also hard to get the funds to roll out such a product for the entire firm. Therefore, pricing has been a limiting factor for us. However, it's a fair price, and I'm confident that we can sell this story appropriately.

I think OWASP Dependency-Check was evaluated before Nexus Lifecycle.

Nexus Lifecycle was chosen primarily for the quality of its scan results.

Look into the API early. Try to scan as much as possible to get an impression of your landscape before you start rolling it out, then you can easily target the teams and applications mostly needed.

The solution makes it easier for us to deploy secure applications. On the other hand, it also introduces a new something that developers didn't really care about before. In some cases, it increases time to market, but for very good reasons. We produce more quality products.

If you consider that developers would test their own research in the past, then their productivity should increase. Unfortunately, most of the time, the hygiene of open source components is a new topic. This is basically new work that we are introducing, so it's hard to compare it to something that wasn't properly done before.

I would rate the solution as an eight (out of 10).

We haven't used the grandfathering feature.

Our primary use case is preventing major security vulnerabilities.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Technical support has been really prompt.

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

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

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

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

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

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

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

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

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

We use it to automate DevSecOps.

Previously, the developers would do their work and then it would be evaluated using something called penetration testing. With the results of the penetration testing they would go back and make changes, and then we would have to do the penetration testing again. That was a very long-winded process, whereas now, they can develop with confidence knowing that the libraries and binaries that they are using have already passed penetration testing. That saves a lot of time in the lifecycle. It's difficult to even quantify because it's so huge. But we're talking about reducing the development lifecycle by about 90 percent, minimum.

It has helped developer productivity. It's like working in the dark and all of a sudden you've got visibility. You can see exactly what you're using and you have suggestions so that, if you can't use something, you've got alternatives. That is huge.

When developers are consuming open-source libraries from the internet, it's able to automatically block the ones that are insecure. And it has the ability to make suggestions on the ones they should be using instead.

Also, you can get reports, either in PDF format or in JSON. If you get them in JSON you can have them ingested into something like Splunk, so you can mine those reports as well.

The application onboarding and Policy Grandfathering features are new and quite useful. They allow you to focus on what you're currently working on and the stuff that's grandfathered can go in your backlog. It's another feature that helps organize your workload.

The data is as good as can be. It's online, which means if a change is made to the Nexus database today, or within the hour, my developers will benefit instantly. The security features are discovered continuously. So if Nexus finds out that a library is no longer safe, they just have to flag it and, automatically, my developers will know. In addition to that, anything that I've used in the past will also flag up. Because it's proactive and it's live data, you know instantly if any part of your application is now vulnerable. Not only that but when you get the information about the vulnerability, part of the Lifecycle mechanism actually gives you alternatives that you can use.

It also integrates well with your existing DevOps tools. They've got very good plugins for most of the common DevOps tools, like Jenkins and GitHub. There are ways that you can work around things like TeamCity. The product is designed to help the DevOps process to be seamless in terms of security.

Regarding open-source intelligence and policy enforcement across the SDL, that's exactly what they're trying to do. They realized that there's so much ingestion of open-source software in most of the software development lifecycles, that there was a need to automate the detection of the ones that are not deemed to be safe. What Lifecycle does to its Firewall product is that, as the binaries are being ingested, it's able to fingerprint them. And because there's a fingerprint, it can check with the Sonatype website and tell you exactly what you're ingesting. If what you're ingesting is not secure, it can block it. Then, you can manually say, "Okay I understand, use this." Or you can go with the suggestion that Sonatype gives you, which is a more secure alternative. So we use it to automate open-source governance and to minimize risk.

There is also a feature called Continuous Monitoring. As time goes on we'll be able to know whether a platform is still secure or not because of this feature. It's integrated, it's proactive, it's exactly what you want for a security product.

They could do with making more plugins for the more common integration engines out there. Right now, it supports automation engine by Jenkins but it doesn't fully support something like TeamCity. That's where they could make the most improvements.

In terms of features, the reports natively come in as PDF or JSON. They should start thinking of another way to filter their reports. The reporting tool used by most enterprises, like Splunk and Elasticsearch, do not work as well with JSON. They should improve the reporting so that the format can be expanded.

The stability is very good. It probably needs to be improved a bit more. The cluster technology is first-generation and is still maturing. It needs to mature a bit more.

IQ is quite stable. It's a very simple engine, it takes something in, makes a decision, and then gives you the output.

The scalability is good but it can be improved. I think they're working on it, but it needs to be clusterable. The best case is to have a cluster, a native cluster, for IQ Server, to improve the availability.

Technical support is very good and the model that Sonatype has taken is that it is a product company, it is not a service company. You get this great support and it doesn't cost you anything. The support that they provide you is very good and it's free.

We weren't using a previous solution, we were using a different approach which was very old and which doesn't work. It was penetration testing which is very problematic. The way it worked was that an application was made and deployed. Then, you or a specialist firm tested the security of that application. You would get a report saying, "Okay, this is what we found." Then you would have to go back and change the application and, after that, get it tested again. You can see how much time it could take you - three, four, five, six months, a year, two years - to get your application tested. It was very inefficient.

The department that is concerned with best practices was obviously doing its homework and that's when they consulted Sonatype. They had some discussions and then the decision was made that this was the way forward. In fact, it is the only way.

The setup is straightforward. The product itself is counter-intuitive for most people, but the setup is very straightforward. It takes less than ten minutes to set up and deploy it. The policies can also be set up using normal human language. There is an interface to do that, so there's very little programming that's required to help the product become operational.

Our implementation strategy for a product like this is that you want it to be available all the time. Nexus, fortunately, has implemented a cluster for their repositories. You can set up a Nexus cluster for Nexus repositories. Lifecycle is not fully clusterable, so that's an improvement that is needed. They need to make it highly available as a cluster that is Active-Active. Right now, you need to have Active-Passive. 

But it's very easy to set up, it doesn't require super expertise. Any developer or any system admin can do it.

They've made Nexus Repository Manager clusterable. From what I've heard, they are trying to make Lifecycle, IQ Server, clusterable as well.

Since implementation, we have had four or five people involved in maintaining it and making improvements. 

It was done in-house by the people who were employed to work on this product. We did get support from Sonatype. They have what are called "success engineers." Sonatype, being a product type company, doesn't charge you for this service, but they will come and give you some tips if there's anything that you're not sure about, or they will show you what best practices are, which is very good. They are very knowledgeable.

From the word "go," with design and planning, any design that we did we passed on to them and discussed it with them. If there was anything that they didn't like or that diverted from best practices, they would advise about it.

For example, the cluster is supposed to be in the same data center. We did that and what would have suited us best is to have the cluster scattered among a couple of data centers. We did that and then we had to use a strategy were we replicated the data to another data center so that we had disaster recovery capabilities.

We see ROI in terms of better visibility into what we have in our developed software.

I think they looked at competitors but that wasn't my job. I'm familiar with the competitors. They are similar to Sonatype but, possibly, not as comprehensive. There are at least three or four other solutions using different but similar concepts. In my view, they're not as convenient or as good as Sonatype.

My advice is "do it yesterday." You save yourself a lot of money. Even during one, two, or three weeks, it's going to cost you a lot of money to fix the security vulnerabilities that you are ingesting in your development lifecycle. You could be avoiding that by using a product like Lifecycle.

With Lifecycle, the product itself, the intelligence is contained in the implementation called IQ Server. IQ Server has a component called Firewall. The Firewall, as the libraries are ingested into the organization, will scan each and every one of them. Depending on the policies, it's customizable as well. You can put policies there to say, if the library missed this criteria, block it. And you can say, if you block it, "But this library's okay, allow it in." You can waive policies. It's very highly customizable, such that you can block it at ingestion and you've got five other levels through which you could disallow a library. You could block a library from going into your staging or your development.

It will be used by over 2,000 developers in our organization, and that is just Phase One. Other phases will be rolled out, so it will be an enterprise deployment for the whole bank. It's a financial institution, an investment bank that is very big. We may have over 10,000 developers.

For all organizations - but most of all for financial institutions - security is very important. Somebody in the bank gave a mandate that we need to be more secure and this was implemented. The best way is to get the developers into the idea is that, by using the product, they'll be actually be saving themselves some time, because as far as security is concerned, they won't be required to change their programs as much.

I would give this product a nine out of ten, knowing that I'll have a full report of artifacts that would have been ingested into our organization - artifacts that are not secure - if I didn't have the product. That information is priceless.

During the development, if there are new libraries that need to be used, then we scan them first to see if they are secure or valid. If there is a threat, can we avoid it or use alternatives. Also, before each release, it is mandatory for us to scan the code before we go to release it.   

It was installed at the beginning of the year, so I think we are using the latest version.

We rely on the default policies because we are new to the system. We haven't adjusted any policies and are sticking with whatever policies were shipped to us. We are mostly focused on policies 9 and 10 for the highest threat levels. These are the ones which we are focusing right now. We don't want to make any modifications or adjustments in terms of 9 or 10. Mostly, it will be the security officer's decision if we need to update the policies. I'm the manager of the development team and my developers usually will not make any changes in terms of policies.

It provides a very detailed analysis of our library. Then, when some of the scans identify a licensing issue, we look at them and know if we have the license. It sort of scans everything. Without this tool, I don't think that there's even a capability to go through all these libraries, because some of the libraries were introduced by contractors and a developer who no longer works here anymore. When Nexus comes in with its scans, it reports on licensing or other vulnerabilities. This is easier to do instead of asking around.

The most valuable feature is the scanning part, then the report part, as it is quite easy to read. The report part is very important to us because that is how we communicate to our security officer and the security committee. Therefore, we need to have a complete report that we can generate and pass onto them for review.

The solution’s data quality has been pretty accurate. The ones that we are focusing on now are 9 and 10. Once we adjust and scan them again, they are no longer deemed to be the same threat level, which is good. If I replaced the library with a safer one, they still complain that that's not good. So far, we're pretty happy with the quality.

One thing that I would like to give feedback on is to scan the binary code. It's very difficult to find. It's under organization and policies where there are action buttons that are not very obvious. I think for people who are using it and are not integrated into it, it is not easy to find the button to load the binary and do the scan. This is if there is no existing, continuous integration process, which I believe most people have, but some users don't have this at the moment. This is the most important function of the Nexus IQ, so I expect it should be right on the dashboard where you can apply your binary and do a quick scan. Right now, it's hidden inside organization and policies. If you select the organization, then you can see in the top corner that there is a manual action which you can approve. There are multiple steps to reach that important function that we need. When we were initially looking at the dashboard, we looked for it and couldn't find it. So, we called our coworker who set up the server and they told us it's not on the dashboard. This comes down to usability. 

There is another usability thing in the reports section. When the PDF gets generated, it is different from the web version. There are some components from some areas which only reside inside the PDF version. When I generate the PDF for my boss to review, she comes back with a question that I didn't even see. I see on the reporting page whatever the PDF will be generating. The PDF is actually generating more information than the web version. That caught me off guard because she forwarded this to the security officer, who is asking, "Why is this? Or, why is that?" But, she has no idea. I didn't have anything handy because I saw the PDF version, which should be same as what I see on the web. This is a bit misrepresented. I would like these versions to speak together and be consistent. Printing a PDF report should generally reflect whatever you have on the page.

We have been using it for two or three months now.

It is stable.

Users of the solution include our security officer, our application architect, and me. I manage all of the development and the developers who work on upgrading libraries.

Not many people are needed to maintain this solution. We need two or three people. One person is from our service support where the Sonatype Server is deployed and managed. Another person is the application architect who reviews the libraries.

Scalability is not applicable to us at the moment.

The solution is pretty much involved in every release that we have. So, it's quite frequently being used. We don't have current plans to increase usage. We are working on our continuous integration process. Once that's done, then there will be a need to increase usage.

I haven't opened a support ticket yet.

We did not have another solution that we previously used before Sonatype.

We had one job file we used a long time ago (it was over 10 years ago). At that time, we had purchased a license, but nobody has really used it for a really long time.

I wasn't involved in the initial setup.

This was all done by our service support.

This solution has increased developer productivity by 20 percent. They know the version that they need to use. It is a lot easier.

We are still in the process of automating our deployment.

In terms of the developing the IDE, I don't see a big need because we are mostly focusing on enhancing existing projects. We mostly will be focusing on addressing existing issues and vulnerabilities. For a developer to use a new library all the time, this is not a high priority. Right now, we are working on continuous integration continuous deployment solutions. Then, we will integrate the Sonatype Scanner as part of the build, testing, and release.

I would give it an eight (out of 10). Right now, it is sufficient for us to identify our vulnerabilities. It is quite easy to use and not too much trouble.

Our use case for Nexus is to monitor all of our dependencies and the main thing we're using it for is tracking vulnerabilities listed against those.

It gives alerts for new vulnerabilities before our clients do, so we have time to review them, audit them, and determine how we need to proceed with resolving the issues before we get any client communication.

Before we had this in place, we had a much more reactive approach to CVE listings.   Since integrating this, and as we've refined our process over the past eight months or a year, we have moved to a proactive approach allowing auditing and decisions on mitigation before any incoming client submissions.

In addition, it has brought open-source intelligence and policy enforcement across our software development lifecycle. As a component of the lifecycle, it gives us more controls in place. As far as bringing in dependencies goes, we're able to see what a dependency is introducing, from a security and licensing perspective, before we publish a release to the public. So within the build stage, if we pull in a new dependency, Nexus will very quickly tell us whether it has issues or not. And we catch it. It scans in the build stages; we have it checking our staging where we're doing our regression; and it's also monitoring our released branches and letting us know if issues are found in our releases. It really does hit all stages of that lifecycle.

I like the JIRA integration, as well as the email notifications. They allow me to see things more in real-time without having to monitor the application directly. So as new items come in, it will generate a JIRA task and it will send me an email, so I know to go in and have a look at what is being alerted.

The policy engine is really cool. It allows you to set different types of policy violations, things such as the age of the component and the quality: Is it something that's being maintained? Those are all really great in helping get ahead of problems before they arise. You might otherwise end up with a library that's end-of-life and is not going to get any more fixes. This can really help you to try to get ahead of things, before you end up in a situation where you're refactoring code to remove a library. The policy engine absolutely provides the flexibility we need. We are rolling with the default policy, for the most part. We use the default policy and added on and adjusted it a little bit. But, out-of-the-box, the default policy is pretty good.

The data quality is good. The vulnerabilities are very detailed and include links to get in and review the actual postings from the reporters. There have been relatively few that I would consider false positives, which is cool. I haven't played with the licensing aspect that much, so I don't have any comment on the licensing data. One of the cool things about the data that's available within the application is that you can choose your vulnerable library and you can pull up the component information and see which versions of that library are available, that don't have any listed vulnerabilities. I've found myself using that a lot this week as we are preparing for a new library upgrade push.

The data quality definitely helps us to solve problems faster. I can pull up a library and see, "Okay, these versions are non-vulnerable," and raise my upgrade task. The most valuable part of the data quality is that it really helps me fit this into our risk management or our vulnerability management policy. It helps me determine: 

• Are we affected by this and how bad is it? 
• How quickly do we need to fix this? Or are we not affected?
• Is there any way to leverage it? 

Using that data quality to perform targeted, manual testing in order to verify that something isn't a direct issue and that we can designate for upgrade for the next release means that we don't have to do any interim releases.

As for automating open-source governance and minimizing risk, it does so in the sense of auditing vulnerabilities, thus far. It's still something of a reactive approach within the tool itself, but it comes in early enough in the lifecycle that it does provide those aspects.

The biggest thing that I have run into, which there are ways around, is being able to easily access the auditing data from a third-party tool; being able to pull all of that into one place in a cohesive manner where you can report off of that. We've had a little bit of a challenge with that. There are a number of things available to work with, to help with that in the tool, but we just haven't explored them yet.

We're going on our second year using the solution.

I've never had any stability issues with the application. I haven't performed any of the upgrades, but we've never had any downtime and we've never had any issues with notifications or an inability to access the information we need.

The technical support is fantastic. I reached out with a suspected false negative and had a response within hours, and within the next day they had determined that, yes, it was a false negative and, that same day, the notification came in when they had resolved the issue. So within less than 48 hours of reporting a false negative, I had a full turnaround and the result returned in the tool.

Before IQ server we used an open-source solution called OWASP Dependency-Check. We wanted something a little more plug-and-play, something a little more intuitive to configure and automate.

For the initial deployment, it was in place within a couple of days of starting the trial.

We did have an implementation strategy sketched out as far as requirements for success during the PoC go. The requirements were that it would easily integrate into our pipeline, so that it was very automated and hands-off. Part of the implementation strategy was that we expected to use Jenkins, which is our main build-management tool.

In terms of the integrations of the solution into developer tooling like IDEs, Git repos, etc., I wasn't really part of the team that was doing the integration into the pipeline, but I did work with the team. We didn't have any problems integrating it. And from what I did see, it looks like a very simple integration, just adding it straight into Jenkins. It integrated quite quickly into the environment.

At this point we haven't configured it to do any blocking or build-blocking just yet. But that's something we'll be reviewing, now that we have a good process.

We have absolutely seen ROI with Sonatype. The more proactive approach is definitely a return on investment. It significantly lowers the turnaround for responding to incoming issues. It also empowered our support staff to be able to pass along audit results without having to loop in the security team directly. There is a much lower overhead involved when doing it that way.

Also, the ability to better manage our vulnerability management by getting the detailed information from the scan results or the listings, and being able to audit them thoroughly and test them really helps with development resources in our case. We do not have to cram in a bunch of upgrades just for the sake of upgrading if we're constrained elsewhere. It really helps prioritize dev resources.

I don't know if it has directly saved time in releasing secure apps to market. It has definitely made everything more efficient, but unless things are critical and can definitely be leveraged, we don't necessarily delay a release.

The upgrade processes are definitely a quicker turnaround because it allows us to actually target versions that are not vulnerable. But it is hard to quantify whether, in the grand scheme of things, our developers are more productive as developers.

We looked at things like Black Duck, White Source, and White Hat.

The biggest issue, and this is why we went with Nexus, is that there were more results and there were far fewer false positives than in the other tools.

Take some time configuring your notifications and your JIRA integration properly, along with the policy tweaks. As you integrate and as you first deploy the tool, don't block any builds until you start to catch up on any issues that may be there. Really spend some time with that policy review and make sure it encompasses and aligns with your vulnerability management policy appropriately.

It is incorporated in all of our software branches, and we keep our most recent end-of-life branch active in it just to monitor for critical issues, so we can notify the community to upgrade. We may also add our new mobile application to it.

Nexus Lifecycle is definitely a nine out of 10. I would say 10 if it were a little easier to get the audit information out. Again, there are ways around that so I am not taking off much for that. It's a solid nine. The results are amazing. The quality of the data coming back is great. The audit interface is easy to use.

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

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

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

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

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

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

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

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

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

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

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

I've been using Sonatype for about six years.

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

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

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

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

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

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

We pay on a yearly basis.

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

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

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

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

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

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

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

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