Sonatype Lifecycle Reviews

I work for a service-based company where we develop solutions based on customer requirements. That server was currently put up. 

I've also worked with product-based companies, developing software products for end-user requirements. That's my background, working broadly in telecom and healthcare.

This solution is for the client, and we do have internal customers who have been using this solution too.

Sonatype Lifecycle primarily has two main products: 

1. Sonatype Nexus and 
2. Sonatype Lifecycle. 

Lifecycle is mainly used for firewall management. If any issues are detected during the build process, they will be flagged, and each port can be addressed based on firewall and code scanning reports. 

Essentially, it streamlines the process, allowing us to easily identify code snippets that need attention and then act upon those findings.

It's heavily integrated within our organization due to our adherence to HIPAA regulations, which are critical for protecting health information. We ensure regulatory compliance is incorporated into both our code and the applications we develop.

• Detailed Violation Reports: The violation reports provided by Lifecycle are key, giving specific details on the types of violations and identifying the component within the application. Even with multiple components like web, app, and database tiers, each is evaluated separately through individual pipelines, and reports are provided for each.

• Version Tracking: Another important aspect is the version details, showing which version is causing issues. We follow a standard release naming convention (major, minor, patch), so we can easily see which version is problematic.

• Dependency Management: Additionally, we can address dependency-related information at a granular level, identifying component versions causing build blockages. This is a very helpful feature.

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. 

We are using the Nexus Repository Manager Pro as exactly that, as an artifact repository. We tend to store any artifact that our application teams build in the repository solution. We also use it for artifacts that we pull down from open-source libraries that we use and dependencies that come from Maven Central. We use it to proxy a few places, including JCenter. We also use it as a private Docker registry, so we have our Docker images there as well.

We're on version 3.19. We also have Nexus IQ server, which wraps up within it Nexus Firewall.

We have a lot of legacy applications here and they're all built with Ant scripts and their dependencies come from a shared folder. There's not a lot of "accountability" there. What we get out of using Nexus is that all of our dependencies are in the same place and we can specify a specific version. We no longer have a situation where somebody has pulled down a .jar file and stuck it in this folder and we don't know what the version is or where, exactly, it came from. That's one of the benefits.

Another of the main things we get is what Sonatype calls a "bill of materials." We can go into our Nexus product and say, "Okay, here is our ABC application. What are its dependencies?" And we can be specific down to the version. We know what's in it and, if a vulnerability gets reported, we can look and see if we use that particular component and in which applications, to know if we're vulnerable. If we find we're exposed to that vulnerability we know we need to go and remediate it.

The biggest benefit we get out of it is the overall ease of development. The ability to automate a lot of the build-and-deploy process comes from that.

The data quality helps us solve problems faster, as in the security vulnerability example I just mentioned. In those circumstances, we have to solve that problem. Previously, we wouldn't have seen that vulnerability without a painstaking process. Part of the Nexus product, the IQ Server, will continually scan our components and if a new CVE is reported, we get that update through Nexus IQ. It automatically tells us, "Hey, in this open-source library that you're using, a vulnerability was found, and you use it in these four applications." It immediately tells us we are exposed to risk and in which areas. That happens, not in near real-time, but very quickly, where before, there was a very painstaking process to try to find that out.

A year ago we didn't have DevOps tools. We started building them after I came on. But Nexus definitely integrates very well with our DevOps tools. Sonatype produces plugins for Jenkins to make it seamlessly interact, not only with the repo product, but with the Nexus IQ product that we own as well. When we build our pipelines, we don't have to go through an array of calls. Even their command-line is almost like pipeline APIs that you can call. It makes it very simple to say "Okay, upload to Nexus." Because Jenkins knows what Nexus is and where it is — since it's configured within the Jenkins system — we can just say, "Upload that to Nexus," and it happens behind the scenes very easily. Before, we would have to either have run Maven commands or run Gradle commands via the shell script to get that done. We don't need to do that sort of thing anymore.

The solution has also brought open-source intelligence and policy enforcement across our SDLC. We have defined policies about certain things at various levels, and what risks we're willing to expose ourselves to. If we're going to proxy a library from Maven Central for example, if the Nexus IQ product says it has a security-critical vulnerability or it's "security high" or it's "component unknown," we can set different actions to happen. We allow our developers to pull down pretty much anything. As they pull something down from say, Maven Central, it is scanned. If it says, "This has a critical vulnerability," we will warn the developer with the report that comes out: "This has a security-critical vulnerability. You're allowed to bring it down in development, but when you try to move to QA or staging, that warning about the 'security-critical' component will turn to a failure action." So as we move our artifacts through that process, there are different stages. When someone tries to move that component to our staging environment, it will say, "Oh no, you can't because of the security-critical thing that we've been warning you about. Now we have to fail you." That's where we get policy enforcement. Before, that was a very manual process where we'd have to go out and say, "Okay, this thing has these vulnerabilities, what do we do with it?" It's much more straightforward and the turnaround time is a whole lot faster.

Automating open-source governance and minimizing risk is exactly what Nexus is for. Our company is very security conscious because we're governed by a number of things including the Fair Credit Reporting Act, which is very stringent in terms of what we can and cannot have, and the level of security for data and information that we maintain. What Nexus does is it allows us to look at the level of risk that we have in an application that we have written and that we expose to the companies that subscribe to us. It's based on the components that we have in the application and what their vulnerabilities are. We can see that very clearly for any application we have. Suppose, all of a sudden, that a Zero-day vulnerability — which is really bad — is found in JAXB today. We can immediately look for that version in Nexus. We can see: Do we have that? Yes, we do. Are we using it? Yes, we are. What applications are we using it in? We can see it's in this and that application and we can turn one of our teams to it and get them to address it right away.

I don't know exactly how much time it has saved us in releasing secure apps to market, but it's considerable. I would estimate it saves us weeks to a month, or more, depending upon the scope of a project.

And it has definitely increased developer productivity. They spend a lot less time looking for components or libraries that they can download. There was a very manual process to go through, before Nexus, if they wanted to use a particular open-source library. They had to submit a request and it had to go through a bunch of reviews to make sure that it didn't have vulnerabilities in it, and then they could get a "yes" or "no" answer. That took a lot of time. Whereas now, we allow them to download it and start working with it while other teams — like our enterprise security team — look at the vulnerabilities associated with it. That team will say, "Yeah, we can live with that," or "No, you have to mitigate that," or "No, you can't use this at all." We find that out very much earlier in the process now.

It allows us to shift gears or shift directions. If we find a component that's so flawed that we don't even want to bring it into the organization from a security standpoint, we can pivot and say, "Okay, we'll use this other component. It doesn't do everything we needed, but it's much more solid."

We use Sonatype Lifecycle for scanning our SCA product, software composition analysis. It is a category of product we use to scan third-party packages imported into the source code like Java, Node.js, or Python. 

It reports back as an enterprise product with UI reports and is very useful. We integrate it into our pipelines, generate reports, and our developers engage with it to fix issues and ensure the software supply chain is secure.

The solution provides a comprehensive overview of dependencies and their security status. The onboarding process is straightforward, and the UI is very clear. The integration into our CICD pipeline enables us to continuously monitor code changes and identify new vulnerabilities. This ensures we can address issues proactively. Lifecycle effectively manages dependencies and highlights unsecure packages. It does what it does better, with integration into other Sonatype products. This integrated ecosystem is advantageous for us.

We use the Nexus IQ Server. That is the only product that we use, though there are other affiliated products Sonatype offers which integrates with it. We use it to categorize and index all libraries used in our software. Every time that a new build is created in our CI server, Nexus IQ server will check exactly what libraries that we're using. It does this for our Java libraries, JavaScript, and other things that it finds. Then, it checks a number of things for each of those libraries. E.g., it checks the license that is being used in it. Sometimes with open source software, the license is a bit more restrictive than might be convenient for what you are doing. Maybe it doesn't allow you to make changes to the library. Or, it's free to use for nonprofits, but if you're using a product which does make a profit, then you might have to purchase a license. Therefore, it protects us from accidentally misusing open source software and is protection against legal issues.

A bigger, ongoing use case is security. Sonatype checks security vulnerabilities that come up for all these libraries. Oftentimes, as a developer, you add a library that you want to use, and then you might check for security issues. Sometimes a problem comes up after your product is already live. IQ Server checks all libraries that we're using for security issues, reporting these, and allowing us to go through and see them to determine, "Is this something that we can waive?" It might be a very specific use case which doesn't actually affect us or we might have to mitigate it. Also, if a vulnerability or security issue is found in libraries later, it will send out alerts and notifications if a library is being used in our production environment, letting us know there is an issue. This allows us to address it right away, then we can make the decision, "Do we want to do a hotfix to mitigate this? Or is it something that isn't an issue in our case because we're not using it in a way that exposes the vulnerability?" This gives us peace of mind that we will be notified when these types of things occur, so we can then respond to them. 

One of the things that it detected was a small library that we use to generate PDFs. It pointed out this needed a purchased license. We had already bought the license because we did have some people in-house who were aware of that. However, it's still one of those things where I can see this easily going wrong for companies who are younger and don't pay as much attention to this type of stuff.

When IQ Server finds a problem a Jira ticket is created and an email is sent out. Usually, one of our technical people will check it out right away to see if this is something that can be simply scheduled in the next sprint or if it's something big. If it is something big that affects us and needs to be addressed right away, I know that we would likely be able to address it almost immediately, either by doing an update of the library or mitigation. We should be able to start work on it almost immediately. In very severe cases, we should be able to do this in just a matter of hours. We should be able to update our environments after we get a notification that the problem exists.

We have had cases where we wanted to add certain libraries, but the Nexus IQ IDE plugin showed there were some security issues with this library. Instead of using it, we found an alternative right away. Because it is easy to have this information available, it saves us the hassle of having to refactor later.

Nexus IQ Server has made it easier to address company or legal policies when it comes to the libraries we use. Sometimes, as a developer, you don't think about the legal aspects of a free and open source software. While we were aware that you occasionally need to buy a license for something, we're also paranoid of falling victim to giant lawsuits because we overlooked something in the license. We did have some enforcement of this before using Nexus IQ Server, but it would be done periodically and sometimes long after implementation of a problematic library was already done. Now it's all categorized in one place and we can very easily check license issues ahead of time. The awareness was there before, but now we have a definite way that it's all completely indexed. Enforcement is now easier and nothing can slip through the cracks. Everything is checked and will be reviewed unless someone specifically says, "This license is okay and you can use it."

It triggered a review of everything that's used and their licenses, since there are so many different open source licenses. Someone does have to go through each license and actually check off on it, with IQ Server we were able to do that more easily. It provides an ease of mind that if anything really bad would pop up, then it would easily show us in the report that it's there.

Since we started using IQ Server we have received a number of alerts regarding newly discovered security vulnerabilities in libraries we use in production. When that happens we delve in to it almost immediately. Up until now all of them have turned out to be for specific use cases that didn't actually occur in production. Just as a precaution though, we still schedule tickets to have such libraries updated anyway, in case it's later discovered that there are additional use cases that would allow exploitation of the vulnerability in production.

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.

We're using it to change the way we do our open-source. We used to actually save our open-source and now we're moving towards a firewall approach where we are proxy to Maven repos or NPM repos, and we are using those proxies so that we can keep ourselves from pulling in known bad components at build time. We're able to be more proactive on our builds.

It's allowed our developers, instead of waiting till the last minute before a release, to know well ahead of time that the components are bad and they are able to proactively select different components that don't have a vulnerability or a licensing issue.

Also, the solution's data quality seems to be good. We haven't had any issues. We're definitely able to solve problems a lot faster and get answers to the developers a lot faster.

And Nexus Lifecycle integrates well with your existing DevOps tools. We were able to put it right into our build pipelines. We use Jenkins and we're able to stop the builds right in the actual build process whenever there's a quarantined item.

In addition, it has brought open-source intelligence and policy enforcement across our SDLC. It has totally changed the way we do our process. We have been able to speed up the approval process of OSS. Given the policies, we're able to say, "These are okay to use." We've been able to put in guardrails to allow development to move faster using the product. Our pipelines are automated and it is definitely a key component of our automation.

Finally, the developers like it because they're able to see and fix their issues right away. That has improved. For example, let's say a developer had to come to us and said, "Hey, scan this. I want to use it," and we scan it and it has a vulnerability. They've already asked us to do something that they could have done through the firewall product or Lifecycle. Suppose it takes us a day and then we turn around and say, "Okay, here are the results," and we say they can use this version of that product. They've got to download it and see if it works. So we're already saving a day there. But then let's say they have to send it off to security to get approval on something that security would probably approve anyways. It's just they didn't know security would approve it. They would have to wait two or three days for security to come back and give them an answer. So we're looking at possibly saving four days on a piece of code.

We manage the overall software development security organization, encompassing assistance to all developers across our organization worldwide. Our 10,000 developers help identify vulnerabilities in their code. We use Fortify Static Code Analyzer to explore methods to expedite vulnerability detection and remediation through a self-service pipeline.

Initially, we utilized Just Cloud, but subsequently, we developed our on-premises tools over the ensuing year. This resulted in substantial cost savings, as on-premises security solutions are generally more economical than their cloud-based counterparts.

Fortify Software Security Center, often abbreviated as SSC, offers both an on-premises and cloud-based version. The cloud-based version is called Fortify On Demand or FOD. FOD is a popular choice for organizations that want a flexible and scalable solution, while the on-premises version is preferred by organizations that require more control over their security infrastructure. OpenText, the vendor of Fortify, offers various consumption models for its solutions. Users can pay per scan or opt for an annual subscription with unlimited scans. However, annual subscriptions can be expensive, with some organizations paying millions of dollars per year. Using the on-premises tools can provide significant cost savings compared to cloud-based solutions, but it also requires a dedicated team of IT professionals to manage and maintain the infrastructure. If an organization lacks the resources to manage on-premises tools, FOD is often the most affordable and robust solution available. In comparison, competitors like Synopsys and Checkmarx typically charge even more for their cloud-based solutions.

The Fortify portal is well-suited for managing and tracking risks associated with the open-source components used in our software projects. The increasing availability of open-source options has been beneficial. OpenText's acquisition of Debricked a couple of years ago has further enhanced its capabilities in this domain. They continue to utilize Sonatype within the FOD, providing customers with a choice. For existing Sonatype customers who have been using the tool as Micro Focus' and OpenText's partner for FOD for many years, continuing with Sonatype remains a viable option. However, for new users or those seeking an alternative to Sonatype, Debricked, now OpenText's open-source security tool, is an excellent choice, seamlessly integrated into FOD.

Utilizing Fortify to identify vulnerabilities has become remarkably effortless. Based on my experience, I've observed a significant increase in user satisfaction with the tool. Over the years, we've acquired several companies that initially held negative perceptions of Fortify, stemming from its previous reputation as a cumbersome and resource-intensive tool. However, with the introduction of FOD and the enhanced capabilities of the on-premises tools, we've witnessed a dramatic shift. The availability of lightweight on-premises tools, coupled with seamless IDE plugins for Visual Studio, Eclipse, and other intelligent IDEs, alongside integrations into Azure and Jenkins pipelines, has significantly empowered users to conduct self-service vulnerability scans in minutes, a stark contrast to the time-consuming hours it previously required.

Fortify enhances our vulnerability remediation efforts by providing more reliable results. Secure Code Warrior integration plays a significant role by providing developers with access to secure coding training, which I believe positions them better to identify and resolve issues promptly. Many companies lack access to this level of guidance and often rely on standard verbiage. I appreciate that users can leverage Secure Code Warrior's guidance for their Fortify findings. This capability is not offered by any other company in the space. Additionally, they have recently partnered with MAB to offer automated code remediation solutions. Automated code remediation means that if I'm a developer and Fortify identifies a vulnerability, instead of manually fixing it, MAB, their partner, can automatically resolve the issue by providing a prebuilt fix and incorporating it into our build pipeline.

Fortify enables our developers to build secure code from the beginning. I can speak with confidence that without Fortify, we wouldn't have fixed thousands of vulnerabilities, and it is helping to streamline that process for developers, whereas Many other security teams rely on traditional PAN testers, Fortify has given our developers the confidence to be able to find, fix, and remediate issues, and a fully self-service mechanism that few other companies have.

Both Fortify and Sonatype have excellent integrations with compliance frameworks such as GDPR, PCI, and DSS, providing comprehensive reporting capabilities that help us meet regulatory requirements. These integrations enable us to stay abreast of evolving regulatory requirements and ensure that our vendor partners promptly address any changes. For example, when the OWASP categories were updated two years ago, both Fortify and Sonatype quickly released support for the updated categories, allowing us to seamlessly update our reporting without delay.

Fortify mitigates risk exposure in applications by identifying vulnerabilities and weaknesses. It pinpoints all the issues that developers need to address and provides comprehensive guidance for remediation.

It provides robust details about the issues, along with comprehensive insights into what needs to be fixed. The ability to see all of the different versions in Sonatype results has been particularly helpful as an indicator.

Fortify's expansion into shift-left security for cloud-native applications has been an exciting development. I wasn't expecting them to venture into this area, but I'm pleasantly surprised by their progress. It appears that they are well-positioned to gain significant market share.

Fortify has helped free up our staff time for other projects by improving our automation capabilities. As a result, we have been able to significantly reduce our turnaround time for remediation tasks. This has allowed our developers to focus on more strategic initiatives, such as automation and engineering, instead of being bogged down with manual remediation work. We have saved over $40 million in headcount expenses by automating these tasks. It would have taken over 100 years to fix all of these issues manually, using our previous processes. In other words, Fortify has automated millions of hours of work, equivalent to the work of hundreds of thousands of people over decades. This is one of the most significant automation projects we have ever undertaken.

Identifying vulnerabilities using Fortify early in the software development life cycle has resulted in significant cost savings compared to discovering them later on. Fortify has enabled us to detect and remediate these types of issues at the beginning of the SDLC. As a result, we can prevent potential problems from reaching the production stage.

Fortify integrates seamlessly with other solutions, which is a significant advantage in our opinion. As I mentioned earlier, Synopsys has struggled with third-party integrations. In contrast, Fortify has taken the lead in collaborating with Secure Code Warrior, reconciled, and MOB to facilitate these integrations. This has allowed us to establish an ecosystem of solutions from various providers that are at the forefront of innovation.

We have integrated Fortify with Sonatype, Secure Code Warrior, and MOB. The integrations take no more than a few hours.