Sonatype Lifecycle Reviews

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I started installing it at the beginning of this year.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

Our primary use cases involve monitoring and securing our software supply chain. We use it to proactively identify and block any potentially insecure components from being downloaded, ensuring our firewall remains robust. Additionally, we use the platform to analyze both deployed and developing code throughout the development lifecycle.

The most valuable function of Sonatype Lifecycle is its code analysis capability, especially within the specific sub-product focusing on static analysis. This feature, particularly tailored for Java code, has been crucial in identifying and addressing vulnerabilities in our software.

There is room for improvement in the code analysis aspect of Sonatype Lifecycle, specifically in the area of deployment security. While the product effectively scans components and provides threat intelligence, it requires additional manual effort to ensure that the configuration of the product during deployment is done securely.

When it comes to new features, I would find it incredibly beneficial if Sonatype Lifecycle could integrate with deployment tools, enabling real-time identification of any vulnerabilities as developers push code to production.

It is a quite stable solution. I would rate the stability as a seven out of ten.

I would rate the scalability of the solution as a ten out of ten. It is suitable for any business size.

I would rate Sonatype's technical support a solid ten out of ten. They are highly engaged, conduct weekly meetings to discuss the product roadmap and competition, and even bring in engineers to provide hands-on guidance on using the product.

Positive

Setting up Sonatype Lifecycle can be complex, possibly influenced by deployment choices. While I haven't explored the latest architecture, there is potential for a simpler SaaS deployment. It is available both as an on-premises and cloud-based hybrid solution to suit different preferences and needs.

I would rate the affordability of the solution as an eight out of ten.

Overall, I would rate Sonatype Lifecycle as a six out of ten. It is a solid product with some room for improvement.

We use this solution for libraries in our applications that need to be updated.

The solution is very easy to use. 

Improvements are needed as per customer requirements.

I have been using Sonatype Lifecycle for one year. 

The scalability is a ten out of ten. 

Overall, I would rate the solution a ten out of ten. 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I would rate their support at nine out of 10.

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

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

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

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

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

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

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

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

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

Cost is a drawback. It's somewhat costly.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Everything else has been really good.

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

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

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

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

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

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

We did not have a previous solution.

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

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

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

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

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

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

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

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

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

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

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