Sonatype Lifecycle Reviews

We're consultants and it supports our primary banking group in Italy in terms of cybersecurity strategies.

Due to the mandatory use of Sonatype within the Italian banking industry, we rely on both Fortify and Sonatype to conduct a comprehensive analysis of the implemented code.

We use both SaaS and on-premise versions. The on-premises software helps the developer team continuously analyze tools. The SaaS version is used for centralized analysis in a testing environment for the IT security team.

Sonatype acts as a mandatory gatekeeper for accessing open-source libraries. Combining Sonatype and Fortify provides an invaluable holistic view of the application code developed by the factory. This includes both the library used by the factory to simplify development and the library itself, enabling comprehensive vulnerability detection. While Sonatype doesn't directly control the coding within the library, it effectively identifies vulnerabilities lurking within the open-source components. This offers significant value to developers who rely on these libraries, as it helps ensure their work is not compromised by unforeseen vulnerabilities. This information acts as a boost for developers, enabling them to leverage the library's functionality with greater confidence. The combination works like a black box for the developer. Sonatype and Fortify complete each other.

They are one of the market leaders, according to Gartner's Magic Quadrant.

We use Fortify to reduce application vulnerabilities significantly. In the test environment, we don't just use software code review. Before the use of Fortify, we would test the applications; however, using Fortify allows us to test internationally and to align with various compliance requirements, for example, European banking requirements.

It offers efficiency in the deployment of the application. It makes code review much easier pre-deployment. The Fortify FOD Portal is quite useful. It helps centrally manage everything and provides us with a 360-degree view of our AppSec team.

The solution truly supports the development team by giving a clear indication of vulnerabilities and providing suggestions on how to deal with vulnerabilities in a clear manner. There is a lot of useful analysis. It can help us map application libraries.

The software security center, in terms of managing and tracking risks, is good. It's very consistent. In Italy, the culture of risk analysis is very low. However, it provides very clear reporting. It offers great mapping. It maps both the tests and the severity of the vulnerability. It can help support the goals of risk analysis and help prioritize tasks to deal properly with risk. It can support risk analysis effectively.

The testing of the application portfolio is useful. It's also great for regulatory requests, including in the European community. The mapping of the application vulnerabilities provides us a way to respond according to risk.

It's very simple to use Fortify.

We can fully integrate with GitHub. However, we can also migrate in certain scenarios. We can prepare packages subject to analysis and send them to Fortify. It's not difficult. It's very simple.

When Fortify is on-premises with GitHub, remediation is easy. They can suggest and resolve issues directly. Fortify can offer guidance to the development team. So it's not only an identification tool, it's also a tool that can provide remediation for potential vulnerabilities.

Now, in the European Union, it's mandatory to analyze software. Fortify has become a necessary product. We might have started using it before there was a regulatory need. However, we now must have something like Fortify in place.

It helps us reduce risk exposure on applications through the discoverability of vulnerabilities and weaknesses. It's fully satisfactory. It ensures we are being fully compliant. We chose the solution as it is one of the market leaders, according to Gartner. We can only use the best in the market since it's so integral to our compliance requirements. It ensures we are always compliant with internal and external audits.

Fortify does provide real-time feedback on security problems. However, we don't use, at the moment, the functionality of real-time vulnerability analysis during the developer's typing of the code. We check the code afterward.

It's helped us free up staff time. We spend less time fixing software deployments. We've reduced the time to market of the implementation phase by 50%. We can test the applications faster, and we can support a number of projects with the same number of people.

Not all languages are supported in Fortify. They should expand their language offering.

We started to use Fortify in 2019.

We've contacted support in the past during the integration of Fortify. Support is quite proactive. We have periodical monthly calls with support.

Positive

We did not previously use a different solution.

I was not involved in the implementation. There was some integration involved in the setup. However, I can't speak to the level of difficulty involved.

We had the help of a systems integrator during the setup.

In terms of capabilities, the solution has all the capabilities necessary for the activity required. It's more economical than the other Big Three in the market as well. The price, overall, is quite good.

I'm a customer.

For those still using manual methods, I'd recommend something like Fortify that could accelerate the process of analysis. Manual methods require more effort for an organization, and those handling them must have high competence. I'm a modernist. I prefer to have continuous awareness in regard to vulnerabilities. Manual analysis, as well, can be very costly. It takes too much effort. Plus, if you have so many applications, it becomes impossible to manage manually. A business would not be able to support this.

We're fully satisfied with the solution. I'd rate the product ten out of ten. The results they provide are clear. There's continuous development of the product, and with new languages and functionality, it will continue to get better and better.

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

IQ Server is part of BT's central DevOps platform, which is basically the entire DevOps CI/CD platform. IQ Server is a part of it covering the security vulnerability area. We have also made it available for our developers as a plugin on IDE. These integrations are good, simplistic, and straightforward. It is easy to integrate with IQ Server and easy to fetch those results while being built and push them onto a Jenkins board. My impression of such integrations has been quite good. I have heard good reviews from my engineers about how the plugins that are there work on IDE.

It basically helps us in identifying open-source vulnerabilities. This is the only tool we have in our portfolio that does this. There are no alternatives. So, it is quite critical for us. Whatever strength Nexus IQ has is the strength that BT has against any open-source vulnerabilities that might exist in our code.

The data that IQ generates around the vulnerabilities and the way it is distributed across different severities is definitely helpful. It does tell us what decision to make in terms of what should be skipped and what should be worked upon. So, there are absolutely no issues there.

We use both Nexus Repository and Lifecycle, and every open-source dependency after being approved across gets added onto our central repository from which developers can access anything. When they are requesting an open-source component, product, or DLL, it has to go through the IQ scan before it can be added to the repo. Basically, in BT, at the first door itself, we try to keep all vulnerabilities away. Of course, there would be scenarios where you make a change and approve something, but the DLL becomes vulnerable. In later stages also, it can get flagged very easily. The flag reaches the repo very soon, and an automated system removes it or disables it from developers being able to use it. That's the perfect example of integration, and how we are forcing these policies so that we stay as good as we can.

We are using Lifecycle in our software supply chain. It is a part of our platform, and any software that we create has to pass through the platform, So, it is a part of our software supply chain. 

Its engine itself is most valuable in terms of the way it calculates and decides whether a security vulnerability exists or not. That's the most important thing. Its security is also pretty good, and its listing about the severities is also good.

The plugins that are there on the editor are also valuable. Engineers don't have to wait for the entire pipeline to go in and show some results. While they are writing code, it can stop them from writing something that might end up as a security vulnerability.

Its default policies and the policy engine are quite good. So far, we haven't found anything that went through IQ but wasn't caught. We are quite happy with it. The policy engine pretty much provides the flexibility that we need. I haven't seen a case where any of my customers came in and said that they don't have a certain policy in place for IQ, or they wanted to change or remove any policies. At times, they wanted to suppress warnings or altogether skip them if possible, but it doesn't happen or is required very often. 

One area of improvement, about which I have spoken to the Sonatype architect a while ago, is related to the installation. We still have an installation on Linux machines. The installation should move to EKS or Kubernetes so that we can do rollover updates, and we don't have to take the service down. My primary focus is to have at least triple line availability of my tools, which gives me a very small window to update my tools, including IQ. Not having them on Kubernetes means that every time we are performing an upgrade, there is downtime. It impacts the 0.1% allocated downtime that we are allowed to have, which becomes a challenge. So, if there is Kubernetes installation, it would be much easier. That's one thing that definitely needs to be improved.

Some of our engineers came from outside of BT, and there are some features that they are used to from rival products, but they are currently not there in Sonatype IQ. For example, Snyk has a feature to stop a particular check-in from happening at the merge stage in case something is different or wrong. This feature is still in the development phase in IQ. Such a feature would be handy in IQ.

Another area where Nexus can severely improve is the licensing model. I am not worried about the licensing cost, but the way they calculate the number of licenses being used needs to be improved. They have been quite ambiguous in terms of how they calculate who is using Nexus or IQ, and this ambiguity has not been good. At times, we think we have a certain number of customers, but Sonatype says that it is not true, and we have some other number. They haven't been able to explain very well how they calculate that number, which has been a challenge for us.

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

IQ Server is quite stable. I get a report from my team about the availability of my tools, and IQ Server stands pretty great. Its stability is 99.99% for sure. 

Repo has had some challenges with our setup. I'm not sure if that has to do with Repo itself or our own infrastructure. There have been some challenges, but there is nothing noticeable. So, overall, they have been quite good. The only thing is that whenever we have to update the tool, there has to be mandatory downtime, which I would like to avoid with something like a Kubernetes-based system.

I haven't faced any challenges in the scalability of Nexus solutions. We have gone from pretty minimal usage to pretty high usage, and I haven't seen any challenges. It is good. It is not similar to some of the other tools that I have where scalability has been an issue.

We have around 3,000 to 4,000 engineers who use Repo daily. We have around 1,000 to 2,000 users who use IQ Server. Our usage is moderate. It is not extremely heavy. As compared to the other tools that are being used by around 30,000 engineers, the usage of Nexus is not heavy. It is moderate.

My team works more closely with them, but I do get feedback from them. I have worked with their architect, Sola, multiple times, and I can easily rate him a nine out of 10. He has been pretty good. The architecture that he provided has been crystal clear around what we have here in BT. Whenever there was a problem with Nexus Repo, he came to the rescue. He understood what the problem was and could fairly quickly implement it. It provided more help than support. We were trying to scale Nexus to a certain extent, and he was able to assist us quite well. The only area where I felt I did not get what I needed was related to licensing. They have been quite ambiguous in terms of how they calculate the number of licenses, and even he couldn't clearly tell me how the calculations are done. Other than that, he has been fantastic.

Its initial setup was done by someone who is retired now. He did it five or six months before I joined.

For its maintenance, we have a team of three people. We have one SME and two support engineers who are dedicatedly there for Nexus and any services that we do through Nexus.

Our ROI is moderate. It has definitely helped us in avoiding a lot of security miscues., but the adoption of IQ hasn't been as much as I would have liked. It has nothing to do with Sonatype. It has more to do with BT's culture and BT's engineers adopting it.

Given the number of users we have, it is one of the most expensive tools in our portfolio, which includes some real heavy-duty tools such as GitLab, Jira, etc. It is definitely a bit on the expensive side, and the ambiguity in how the licenses are calculated adds to the cost as well. If there is a better understanding of how the licenses are being calculated, there would be a better agreement between the two parties, and the cost might also be a little less. 

There is no extra cost from Sonatype. There is an operational cost on the BT side in terms of resources, etc.

We have evaluated Snyk but not for the same capabilities that IQ has. We didn't evaluate Snyk for open-source vulnerabilities. We evaluated it for container security, Infrastructure as Code security, and other aspects. Snyk does OSS as well, but we are not looking at OSS as a solution offering from Snyk at this time. We are doing a pilot with Snyk to see how they can do other things.

In terms of the open-source vulnerability checks, Snyk has a few more features around stopping mergers to happen and stopping check-ins to happen with integration with Git. This is not something that we have evaluated. It came as feedback from our engineers.

It is quite easy to integrate across the tooling board, but that it does lack a couple of modern and shiny features. It does a pretty good job around the core things of open-source vulnerability check, and it categorizes vulnerabilities pretty nicely. To anybody who wants to use Nexus, I would advise seeing how they can create a bit of a scalable and multi-instance model between IQ and Repo so that they can save on some of the update time that I have to go through.

It has delayed some of the deployments across our supply chain, which is not necessarily a bad thing because delay is only in the case it identifies any issues. One of the challenges in terms of adoption has been that not everybody wants to know how bad their code is. It has been a challenge to make more and more people adopt Nexus IQ, but the quality has definitely improved for those who have onboarded it. There is no doubt about that.

In terms of the reduction in the time taken to release secure apps to market, it doesn't improve the time if you look at a small picture and a single pipeline or component. It reduces time if you look at the larger picture in terms of how many cycles would have been there if you had identified a security vulnerability in the final environment rather than the earlier environment. In such a scenario, it saves time. It doesn't save time in making the code reach production quicker, but it saves time with fewer cycles happening between the development code and the production code. If I go completely by the test count or the engineering count of around 2,000 folks, there is definitely a saving of around 4,000 to 5,000 hours every quarter.

It has not increased the level of productivity for our developers because that's not why we are using Nexus. It has definitely reduced the number of cycles between the production code and the development code.

We don't use the Nexus Container feature. We have a different container that is our own instance. It is a strategic instance for BT that is owned by our own team.

Nexus definitely has been a key component in our portfolio. The big lesson that I have learned from using Nexus is that there are a lot of open-source libraries that are considered okay in a common area. A lot of times, we identified a library that almost everybody considers okay to use but then realized its vulnerability. So, one of the lessons is that you have to be vigilant all the time with what you are using inside your code.

I would rate it an eight out of 10, and that's quite good. I have deducted two points. One of them is related to the licensing model, which should not be that ambiguous. Another one is related to becoming more forward-looking and supporting modern products such as Kubernetes or EKS. The demand of the hour is to have our services up for more than four-nines or five-nines. 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Our company didn't use any other solution.

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

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

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

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

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

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

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

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

I would rate this solution an eight out of 10.

We maintain several applications that utilize a mix of custom PHP packages and native functionality. When a package becomes outdated or a security vulnerability emerges within one, our lifecycle management system flags the issue and assigns a threat level of critical, high, or moderate. We prioritize mitigation based on severity, addressing critical issues first. Additionally, we've integrated Fortify on Demand into our build pipeline. This tool scans our codebase for static vulnerabilities as new code is built and performs dynamic scans for potential runtime issues once builds are deployed.

We implemented Fortify Static Code Analyzer to ensure our platform meets security standards, stays up-to-date with threats, and streamlines security remediation.

We use the Fortify Software Security Center to provide a wide view for our AppSec team.

The Fortify Static Code Analyzer aids in remediating potential vulnerabilities through its accurate and reliable results. It serves as a critical gatekeeper for production applications. If an application fails the Fortify on Demand scan, it does not enter the deployment phase and is effectively halted from release.

Fortify Static Code Analyzer helps our developers build secure code.

While we were able to manage our security issues before tools like Fortify Static Code Analyzer, we relied on manual identification and documentation of vulnerabilities. However, this lacked the efficiency and scalability of an automated solution.

Fortify and Sonatype solutions help us ensure compliance with applicable regulations. We gain valuable insights into relevant regulations directly from vulnerability assessments, which helps maintain compliance with specific regulations.

Fortify Static Code Analyzer offers feedback on security vulnerabilities. Its static and dynamic scan, particularly for Fortify on Demand, provides automated feedback. For example, the dynamic scan might take around 20 minutes to settle, depending on the specifics. However, this turnaround time is significantly faster than relying on the entire security team to conduct manual testing. It can sometimes provide excessive detail that is not directly pertinent, leading to inefficiencies in extracting the relevant information.

I believe Fortify Static Code Analyzer is a valuable tool for implementing shift-left security in cloud-native applications. I intend to leverage it for personal projects, starting with my current app development. I plan to make it my go-to standard for application security.

The ability to identify vulnerabilities using Fortify Static Code Analyzer early in the development life cycle has saved us costs.

Integrating Fortify Static Code Analyzer is not complicated after the first integration.

Automating the Jenkins plugins and the build title is a big plus.

Fortify Static Code Analyzer has a bit of a learning curve, and I don't find it particularly helpful in narrowing down the vulnerabilities we should prioritize. It throws everything at us at once, which can be overwhelming. While it's not a major issue, I'd like to see it focus on critical vulnerabilities and highlight them upfront. Furthermore, categorizing critical vulnerabilities by platform-specific vulnerabilities and relevance to supported features would be incredibly beneficial.

While Fortify Static Code Analyzer has some merit, I believe it still has significant room for improvement. We have encountered a high number of false positives, which has been a major obstacle and resource drain.

I have been using Fortify Static Code Analyzer for two years.

We use it in combination with Sonatype Lifecycle. We use Sonatype for all of our packages. It's for any outdated packages that we have. Before we build a package out to production, we can see if we need to update it. Having that alongside Fortify makes it our own one-stop shop for security. It makes our builds a lot smoother.

I would rate the stability a seven out of ten. Fortify Static Code Analyzer suffers from limitations in handling versioning issues. It necessitates specific guidelines or calls to operate efficiently otherwise it doesn't provide feedback.

We are still trying to get an impression of the scalability. We have scaled it on all of our products and it seems to be good. I would rate the scalability an eight out of ten.

The technical support is adequate, but I did experience a frustrating issue once. They could benefit from a dedicated team to handle support requests more efficiently. Messaging them and relying solely on the support ticket system feels outdated, especially considering the premium price we pay. At least a live chat option would be a significant improvement, as the current system was quite cumbersome and unresponsive.

Neutral

The initial deployment was a bit more challenging than anticipated. There was a learning curve involved, and supporting the plugin for our Jenkins environment presented a significant obstacle.

To overcome these hurdles, we decided to evaluate the Fortify Static Code Analyzer. We began by integrating it into smaller projects first, which allowed us to gain familiarity with its capabilities. We then gradually branched out to our larger projects, building upon our understanding. This involved uploading code bases, analyzing the scans, and interpreting the results. By taking this incremental approach, we were able to effectively expand.

Four people were involved in the deployment.

We have seen a return on investment using Fortify Static Code Analyzer.

We evaluated other solutions but ultimately selected Fortify Static Code Analyzer for its simplicity and its ability to tailor to our build cycle.

I would rate Fortify Static Code Analyzer a seven out of ten.

Since we started the integration of Fortify Static Code Analyzer from the beginning, it has not yet significantly freed up the time of our security team. However, it has helped make the process more efficient, and the integration is still in progress.

Organizations that are still using manual methods to find vulnerabilities should try Fortify Static Code Analyzer. If it is within their budget, Fortify Static Code Analyzer will work well for them.

We utilize the Fortify Static Code Analyzer across various locations and projects, making it the go-to tool for security analysis in most of our development initiatives. We are a large corporation with high traffic.

For larger platforms with strong automation needs, I recommend Fortify Static Code Analyzer.

We are a development company and a staff provider, so we have 100 plus developers and use the open-source library.

The IQ server and repo are the most valuable.

The reporting could be better.

We have been using this solution for about a year and a half, and the IQ server is 148.

We've been running for almost a year and a half and have not faced any service degradation or outage. There have been times when we need to upgrade and plan, so I rate the stability a nine out of ten.

I rate the scalability an eight out of ten.

The technical support is good because we have a success manager allocated to us. So we usually go to the success manager for support, and it's really good. Otherwise, we never go to the support portal. The success manager can help us immediately through email.

The initial setup was straightforward, and it is cloud-based. It's hybrid, so the main items are in cloud, but we use on-premises to support our design. We have almost 14 development teams working with different languages. It took two weeks for complete coverage and deployment readiness, but everything took about four to six months.

We completed the deployment in-house, so we had a success manager from Sonatype. Sonatype also provides some guidelines. I completed the deployment, and I am not a technical person. There's a shortage of resources, and I was able to do it, so it is a one-person job. A medium-skilled person can complete it with an average skill set. However, you may need a dedicated resource if you want to move to a maturity level.

We have about 100 developers using this solution. Sometimes we have an extra workload, but we maintain those 100 developers at the core on average. That is an organizational policy so that the workload will be balanced accordingly.

We are a development company, and we use open-source heavily, like 95% source code. So the return on investment on the main security check is very high.

Their pricing is within the same range as the enterprise bundle, around $50,000 US dollars.

I rate the solution an eight out of ten because of the compatibility and the cost. In the market, some products cost less. Regarding advice, Sonatype Nexus Lifecycle provides many capabilities. If you want to use it, you should be able to prioritize your need for it. In addition, you should be ready to clear through the pipeline, which will make the program successful. If they are a traditional company and opting for IQ, there may be challenges, and there will be better results if it is already adopted.

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're using Sonatype Nexus Lifecycle to scan for vulnerabilities in our continuous integration and deployment pipelines. We're also using the solution as part of our IDEs for developer support.

Due to the sheer amount of vulnerabilities and the fact that my company is still working on eliminating all vulnerabilities, it's still too early for me to say what I like most about Sonatype Nexus Lifecycle. Still, one of the best functions of the product is the guidance it gives in finding which components or applications have vulnerabilities.

For example, my team had a vulnerability or a CVE connected to Apache last week. My team couldn't find which applications had the vulnerability initially, but using Sonatype Nexus Lifecycle helped. My team deployed new versions on that same day and successfully eliminated the vulnerabilities, so right now, the best feature of Sonatype Nexus Lifecycle is finding which applications have vulnerabilities.

It could be because I need to learn more about Sonatype Nexus Lifecycle, but as a leader, if I want to analyze the vulnerability situation and how it is and the forecast, I'd like to look at the reports and understand what the results mean. It's been challenging for me to understand the reports and dashboards on Sonatype Nexus Lifecycle, so I'll need to take a course or watch some YouTube tutorials about the product. If Sonatype Nexus Lifecycle has documentation that could help me properly analyze the vulnerability situation and what the graphs mean, then that would be helpful.

I need help understanding what each graph is showing, and it seems my company is the worst, based on the chart. Still, I need clarification, so if there were some documentation, a more extensive knowledge base, or a question mark icon you could hover over that would explain what each data on the graph means, that would make Sonatype Nexus Lifecycle better.

I've been using Sonatype Nexus Lifecycle for almost a year.

Sonatype Nexus Lifecycle is a very stable tool; my team hasn't had any issues with it. My company had a significant outage two or three weeks ago, so all storage was lost. Still, in just a short while, Sonatype Nexus Lifecycle was up again, which makes Sonatype Nexus Lifecycle a very good tool.

We haven't scaled Sonatype Nexus Lifecycle yet.

We've just been using Sonatype Nexus Lifecycle, so we can't evaluate its technical support for now.

Sonatype Nexus Lifecycle was the first tool we used with dependency scanning functionality, though we used other vulnerability scanning tools such as Docker and Trivy before Sonatype Nexus Lifecycle. We also scanned for vulnerability in images with Harbor. Sonatype Nexus Lifecycle is the only tool we've used for scanning dependencies.

The initial setup for Sonatype Nexus Lifecycle was straightforward.

We deployed the Sonatype Nexus Lifecycle in-house. We learned how to install and use the product.

We've seen ROI from Sonatype Nexus Lifecycle, mainly connected to the number of attacks. For example, we've calculated the number of hours our employees put into analyzing a vulnerability and looking for that vulnerability in the different components. We saw that the main benefit of using Sonatype Nexus Lifecycle is quickly finding which components have vulnerabilities. As a result, two to three employees save on a week's work because that's how long it takes to look through all the different components with vulnerabilities.

Vulnerabilities could also cause a significant outage or complete data loss, which comes at a high price. Sonatype Nexus Lifecycle could help prevent that or help eliminate the risks. Hence, there's ROI from the tool, but we still need to evaluate the data fully.

In comparison with other tools, Sonatype Nexus Lifecycle could be more expensive. Still, at the same time, my company prioritizes security, so the pricing for Sonatype Nexus Lifecycle hasn't been an issue.

If IT security weren't at the top of the list for my company, somebody would have raised the question about cost and how Sonatype Nexus Lifecycle is in terms of ROI. So far, there's been no question about the price. The cost of Sonatype Nexus Lifecycle hasn't been a problem so far.

My company pays for the license yearly, plus technical support.

We started evaluating four different tools about this time last year, from November to December, and we chose Sonatype Nexus Lifecycle. We were deciding between Snyk and Sonatype Nexus Lifecycle. Still, Snyk lacked support for all our technologies and didn't have the same IDE support available in Sonatype Nexus Lifecycle, so we went with Sonatype Nexus Lifecycle.

We used Sonatype Nexus Lifecycle during the first quarter, from January to February, to establish the tool in our organization and set it up. We then made a training plan and, from March to April, rolled the Sonatype Nexus Lifecycle out to all the teams, but the different teams also had to build their pipelines, so there have been delays from May to the present. We've been pushing them to adjust their pipelines and still helping them.

My company is currently using the latest version of Sonatype Nexus Lifecycle.

About fifty IT department employees use Sonatype Nexus Lifecycle in my small company.

There's no plan to increase the usage of Sonatype Nexus Lifecycle. Its rollout is complete, and only the development teams use the tool within the company.

My rating for Sonatype Nexus Lifecycle is eight out of ten because it does its job, and my team hasn't had any problems with it.

I'd recommend Sonatype Nexus Lifecycle to others.

My company is a Sonatype Nexus Lifecycle customer or end-user.

We use it for checking our open source libraries for Java and .NET. I think they also have Python and R that some of my colleagues are using. And on the other side, of course, we also have the proxy to only download the open source libraries for our internet software development that are free of vulnerabilities and security issues.

It's deployed on-prem. We have internal servers.

Before we had Nexus Lifecycle, our software developers needed to clear each download from open source libraries. That meant they needed to scan the library on a separate PC, and then they would integrate it into their solutions, but it would be local and not available for the other developers. Now, we have an automatic process for downloading open source libraries, and this has removed a huge effort for all of our software developers. That is the big advantage, that we have an automated software development pipeline, which is something we did not have before. All of our developers are happy to have the solution.

Another benefit is connected to the fact that we also have applications we host for external users and those users can obtain a very good report about which external, open source libraries we are using, and their security status. 

We get email notifications if a certain library has a security issue, like Log4j. We are informed very early and we can check into it and act on it. This is the most valuable feature.

Also, the integrations into developer tooling are quite nice. I have the integration for Eclipse and for Visual Studio. Colleagues are using the Javascript IDE from JetBrains called WebStorm and there is an integration for that from Nexus Lifecycle as well. I have not heard about anything that is not working. It's also quite easy to integrate it. You just need to set up a project or an app and then you just make the connection in all the tools you're using.

We have also set up certain organizations for our company, within the Nexus tool, such as groups or departments. Within these groups, we have the different applications they're working with. This is a structure that Sonatype recommended we implement.

We got a lot of annotations for certain libraries when it comes to Java, but my feeling, and the feeling of a colleague as well, is that we don't get as many for critical libraries when it comes to .NET, as if most of them are really fine. It's true that we have more Java applications than .NET, but the number of our applications in the .NET area will increase. Again, it's just an impression, but it seems that the annotations for .NET are not the same as for Java. It would be good if Sonatype would check the status of annotations for .NET packages.

Again, I note that we are just starting to use an open source library from NuGet for the .NET area, while we have been using it for Java for several years and we are using more packages. For .NET, it's evolving. But my impression is that annotations are more focused on Java, and that in .NET we just do not see as many security issues as in Java. It could be fine, but maybe Sopatype started with Java and then expanded the portfolio to .NET and to other languages. This is something which could be further checked.

It could also be the fact that we have had Java applications for around 20 years, using open source libraries. When you go to the newer versions, you need to check and test. Whereas the .NET applications are evolving and are using open source libraries, and the .NET side is really new for our organization.

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

The stability is fine. I have not struggled with it. The solution is working, it's available. But this is something I can't tell you much about it because the server infrastructure and installation are done by our infrastructure team. I'm not sure if they are struggling with availability of the services.

The scalability, currently, is fine, because the performance is fine. It was important to have a structure at the beginning, a way to set up different departments and groups. Now, if we have a new group that will use IQ Server or Nexus Lifecycle, we can just add it and it will be managed by the department. That makes it really good and scalable.

Nexus was a pilot, where some of my colleagues were using it but now it has spread to our whole organization and more colleagues are using it.

An evaluation of Sonatype's technical support is more a question for our infrastructure team.

We did have some workshops with Sonatype about using Nexus Lifecycle and IQ Server, and they were quite nice. They made presentations and we could ask our questions. There is also the offer to have workshops about new topics, but I can't say much about the really technical questions.

However, from my point of view, the communication with Sonatype is really good. They take care of our requests and issues and answer them.

This is the first solution we're using. We had a Nexus repository for several years, and we added Nexus Lifecycle on top in the last one to two years. Before, we would just manually download libraries and clear them by checking the download status. It was a manual task and now it's automated.

I wasn't involved in the server installation. From my point of view, the deployment was quite easy. The servers were set up—a test instance and a production instance. In the test instance, we can play around and see if everything is working.

The IDE integration was quite easy because you just have to download the plugins and then set up the URL and the user and password. With Jenkins, we had to play around a little bit, but it was not that tricky. The integration is really nice because the plugins work quite well.

Because we have only had Lifecycle in production for around one year, it's too early to know if it has improved the time it takes us to release secure apps to market.

But it has definitely increased developer productivity. If you manually download a package, you're not sure if it is the right package because you cannot test it. But now, we can automatically download packages. It's much more effective and more productive for each software developer using it. I would estimate we have seen a 20 percent increase in productivity.

It's also helping our security because that is an aspect we did not check before. That is new for us and very valuable.

We have internal help pages for new software developers with explanations about how they can get access to Nexus Lifecycle and how they can set up new organizations, new applications, and how the IDE integration is done.