Sonatype Lifecycle Reviews

We use the product as a SaaS analysis tool. We review static code. It allows you to find vulnerabilities.

The value that combining Fortify and Sonatype is that we use Fortify as a SaaS analysis tool. We review static code and Sonatype allows you to find vulnerabilities.

I use it as a security center. I review it for any kind of issues, whether for proof or to deny, the source code, the findings, and then the enterprise can go back and provide their recommendation for how to fix the issue. It is used to scan the code base.

As a security analyst, I like the management view. From there, you can review the code and review findings in order to approve, deny, or recommend. Their Software Security Center, which acts as a portal, is quite useful. It's a good overview. You can really see what's happening after you've developed something.

Fortify's AppSec testing is great for application portfolio inventory and project releases. It works both at a portfolio level and also at a project level.

They also give you the capability to click train of all your vulnerabilities that happened within Apache Crossroads support. You give them a history to keep track of them, how they've been developed, how they've been saved, to give you a way of tracking your issues and how they get resolved.

It's pretty easy to find vulnerabilities. Then, you go to the source. It is very good at tracking to see where the data or the issue enters into your source code so you can track it or go back to where it started.

Fortify helps remediate potential vulnerabilities by using more accurate, reliable results. They offer recommended remediation. I can go to the website tools to resolve issues and search for remediations. This helps our developers to build more secure code from the start.

It has reduced vulnerabilities. We've never had issues when we ran our scans. We're notified, and we're able to identify most of our vulnerabilities and fix them before anything goes to production. If you're running this on your CI/CD pipeline, notifications are in real-time.

The level of detail is very informative. It provides you with recommendations on how to fix items. And they provide you with other resources available for how to address the issues. You can also see the root cause.

It works well with cloud-native applications.

Fortify helped us to free up staff time since it helps us resolve issues faster.

It's helped us save costs as, if we catch a vulnerability faster, it's easier to fix than later.

Fortify and Sonatype help maintain compliance with the applicable regulations. We mostly use Sonatype for compliance and licenses. By combining both solutions together, it enables you to solve a lot of issues that may occur in the future.

It would be nice if they had a version suitable for single developers that could be more cost-effective and maybe faster to learn.

I've been Fortify for two or more years.

I've never had an issue with the solution crashing.

I've never had issues with scaling.

I've never had to contact technical support.

I was not involved with the initial deployment.

We only integrated the product with one other solution. It was easy to do so.

There is some general maintenance needed, such as adding or removing users and projects and things of that nature.

Their licensing is expensive.

I do not use the open-source components of Fortify. However, we use other tools for open-source stuff.

I'd advise people who are still using manual methods to find vulnerabilities to adopt some sort of scanner to cut the time spent by 100%.

I'd rate the solution ten out of ten.

I would advise other potential users that you need to make sure your source code can work with Fortify.

We use Fortify Static Code Analyzer and Sonatype in conjunction with Azure DevOps to view all code processes, from scheduling to deployment in production. This is typically included in the build. Therefore, when a colleague performs a build, all scans are automatically done, and they can see the results through the Fortify and Sonatype web portals.

Fortify Static Code Analyzer enables developers to identify and fix broken references within the code. We sought to understand how to write secure code by design.

Finding vulnerabilities using Fortify SAST is not difficult.

Fortify SAST helps our remediation of potential vulnerabilities with accurate and reliable results. While this practice does not allow our developers to build secure code from the outset, as they are currently notified of issues only after the initial build, it does facilitate the creation of secure code before deployment to the customer environment and production.

Fortify SAST has been instrumental in our growth. As a result, I now have a team that consistently writes more secure code without relying on scans. By addressing the same issues repeatedly, we learn to write code correctly the first time, fostering a culture of knowledge sharing. This is facilitated by our weekly meetings where the team discusses key issues and collaborates on solutions.

I can use the dashboard and portal to see our compliance in real-time and address any compliance issues before they become a problem.

The Fortify SAST portal helps me identify vulnerabilities and weaknesses to reduce our risk exposure.

Real-time feedback isn't necessary for us because we receive scan results once a week or on demand. However, the feedback has been incredibly valuable. I can perform a scan and immediately see our current situation. This allows me to quickly assess if our coding practices are effective or if we need to stop and address any issues before they become bigger problems.

Fortify SAST has helped free up around 20 percent of our employees' time to work on other projects.

Fortify SAST's ability to identify vulnerabilities early in the development lifecycle has helped us save significant costs equalling around 40 percent as well as time, as it allows us to catch issues before they reach production. Before using Fortify SAST, we could only identify problems manually, which often resulted in code being deployed with vulnerabilities.

Integrating Fortify SAST is simple and takes around two hours.

The reference provided for each issue is extremely helpful. It allows our team to understand the rationale behind resolving the issue and the specific type of security problem we are facing. This information is crucial for improving our security skills and coding practices. The ability to review and approve each scan before deploying to production is vital. This ensures that our product is free of bugs and complies with our security policies.

The price can be improved.

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

I would rate the stability of Fortify SAST ten out of ten.

Fortify SAST perfectly fits our organization's size.

The technical support is good.

Positive

The initial deployment is straightforward. The integration is part of our DevSecOps process and it is completely transparent.

Whether or not the Fortify SAST deployment is done separately will affect its complexity.

The deployment takes about one week and involves ten people.

Although I am not responsible for the budget, Fortify SAST is expensive.

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

Currently, we don't utilize Secure Center. Instead, we have a dedicated server that collects scan data. Fortify scans are conducted on the server hosting DevOps, which then transmits the results to the Fortify server. Due to our organization's size, Secure Center implementation is not currently necessary.

Organizations that are still relying on manual methods to identify vulnerabilities should consider transitioning to SAST for improved efficiency and professionalism.

We have Fortify SAST deployed in one department and we have 14 users.

Fortify SAST's reliance on Java necessitates maintenance due to our predominant use of Microsoft technologies.

I recommend implementing Fortify SAST for enhanced security, as a SAST solution is crucial to ensuring comprehensive security.

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

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