Sonatype Lifecycle Reviews

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're using it for looking at code libraries, for its automatic build process for cloud. We want to look at code libraries that have security, to make sure that there are no vulnerabilities in the code libraries that people are uploading, and we want to do that early in the process so it's not being caught at the tail end.

We use it to automate open source governance and minimize risk.

• The application onboarding and policy grandfathering features are good.
• The solution integrates well with our existing DevOps tools.
• It also blocks undesirable open-source components from entering our development lifecycle. It scans code libraries and it flags them if there's a vulnerable version. It shows us very quickly if there is a newer version available, and what generation that non-vulnerable version is.

Getting it integrated depends on your structure and how your DevOps teams are structured. The biggest thing is getting it used uniformly across all the different teams. It's more of a process issue. The process needs to be thought out about how it's going to be used, what kind of training there will be, and how it's going to be socialized, how it's going to be rolled out and controlled, enterprise-wide. That's probably more of a challenge than the technology itself. It's pretty simple to get up and running. It's not really an enterprise solution, like Active Directory, which you can enforce on everyone. It's something that's done through each little vertical.

It looks pretty stable to me.

I don't know how well it's going to scale.

We did not have a previous solution. We had nothing.

The setup was straightforward, it was easy to install. On the pilots, it didn't take it long to get it up and running. We only did limited portions. For a pilot, the setup only took a couple of days.

It was pretty much all done internally.

We have one person assigned to this solution for maintenance. It's not being used extensively, and there's no plan to increase it, even though there's a desire to increase use of it. In other words, everyone wants to deploy this, but no one has figured out how they're going to do that enterprise-wide. It's a process problem, not a technology problem.

Overall, I give it a nine out of ten. It has a very intuitive interface and clearly displays the problems and the solution.

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

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

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

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

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

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

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

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

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

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

There are other areas for improvement. 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

It has all the features we need.

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

The stability is great.

I would rate the scalability at eight out of ten.

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

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

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

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

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

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

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

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

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

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

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

Our use case is to check and evaluate third-party libraries for vulnerabilities and licensing problems. We are integrating it into our build pipeline as well.

We're still using it in a PoC and it's not as integrated as it could be so it hasn't changed too much for us right now. But of course, what we want to do is to keep safe, look at the vulnerabilities that come from third-party libraries. It will change our development process and help us improve the security part, the development process.

In the way we are using it now, we have checked several applications manually and gotten some information about vulnerabilities. And we have been able to fix these vulnerabilities with help of the product.

The solution helps automate open-source governance and minimize risk. For example, a developer decides to use an open-source component, so he is going to add Wire Maven into the application. In this phase, he can already get information about possible vulnerabilities. If he ignores this, we can still absolutely detect such a problem later on and prevent it from being sent to production. This is a process which has several steps, of course. We also want to use the firewall to prevent such libraries from downloading, but this is something we haven't done yet.

It has also improved on the time it takes us to release secure apps to market. It was not possible for us, before, to ensure really secure development. But we are still on our way in that regard. Without a tool like this, you can't really find out which vulnerabilities are present. It's only possible if you use such a tool. Because we didn't have this kind of tool before, I cannot say how much time it has saved. I can only say that now it's possible to develop secure applications.

The most valuable feature is that I get a quick overview of the libraries that are included in the application, and the issues that are connected with them. I can quickly understand which problems there are from a security point of view or from a licensing point of view. It's quick and very exact.

The onboarding and policy grandfathering are quite useful, to keep in mind what we have already discussed around parts of the application, and to identify our own parts of the application which are not discovered by Nexus Lifecycle.

The data quality is really very good. We have also checked other products and they do not provide such good quality data. Still, we must look very closely at a single vulnerability from a single issue. We have to understand what problem it's indicating. However, without this tool there would be no way to do this. The data quality is really very good.

It was very easy to integrate into our build pipeline, with Jenkins and Nexus Repository as the central product. It was very easy to integrate the evaluation of the application to be built into the Jenkins process so that we had the ability to check how good the application is thus far. It also helps when you look at the stage we are at in building this application, whether test or production.

If there is something which is not in Maven Central, sometimes it is difficult to get the right information because it's not found.

And if you look at NPM-based applications, JavaScript, for example, these are only checkable via the build pipeline. You cannot upload the application itself and scan it, as is possible with Java, because a file could change significantly, so the applications are not found anymore. This is something that could be improved in future.

Also, I have seen in Black Duck, for example, that there is also information about exploits there are known for a given vulnerability. This is something I haven't seen or haven't found yet in Nexus Lifecycle. If there is a known exploit to a vulnerability, this could be something that is useful to know as well.

Nexus Lifecycle has had no problems until now. There is just a small circle of people using it directly, so this is not a critical mass of users. I cannot say what the stability will be like when there are more people using it. But right now, there is absolutely no problem. It just works.

The users in our company are developers and software architects.

We are using just one instance right now, I don't know how it scales.

We have always had quick responses to questions we had, and they have always been very helpful. The people involved are very smart. They know what to do.

The initial process is straightforward. It took half an hour. We had everything working and then the integration into Jenkins took another half an hour. This was very straightforward. Of course, you must look at the rules and the metrics that are important to you. You must do something regarding the applications you are using and your organizations that are involved. But this is true for every tool.

We are still on our PoC, so there has been no investment up until now. We have just decided to invest in Nexus Lifecycle. I am sure that there will be a return on investment very soon.

Its pricing is competitive within the market. It's not very cheap, it's not very expensive.

We also evaluated Black Duck. We selected Nexus because of the data quality and the ability to integrate it into our build process.

Look very closely look at Nexus Lifecycle to check whether the system is a possibility in your environment. It has good data quality and good integration in our build environment. Everyone must check for themselves whether it is the right solution for them. But I would always advise to have a close look at Nexus Lifecycle, if there are similar requirements to ours.

The Success Metrics feature is something we have not used too much up until now. It's unused because when we started was it was very basic. However, it is a very good means for seeing how successful we have been in reducing the issues that are connected with applications.

We could improve the quality of the third-party libs we are using, and the SDLC is something we are going to improve as well. In this area, we hope Nexus Lifecycle will help us to do so. It's just a part of what there is to do, but Nexus Lifecycle will be very helpful in this kind of process. We can get the information about vulnerabilities and licensing problems very early, when integrating a library into Eclipse, for example. Further on we can scan applications manually and integrate the evaluation into the build pipeline. These things are important as early as possible, but it's also good to have the last look if there is something we do not want in production.

In terms of blocking undesirable open-source components from entering our development lifecycle, we could configure the solution to do so but we haven't done so yet. This is, of course, something we want to do.

As for the tool increasing developer productivity, I would say yes and no. Now we can better deliver secure applications but, on the other hand, there's more to do. Of course, it was just not done before so it would be comparing apples and oranges.

It is possible that we will extend the tool to other development departments, or even to those who are looking at the licenses. We are using it on-premise, right now, and this is something we would continue. We are integrating it with our Jenkins and Nexus-based build pipeline, which is also here on-premise. This is what we are going to do in the next weeks.