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.

We use Fortify SAST to scan our code. It is used for the static code and not the running code. It finds vulnerabilities, and it finds bad practices. If you are using something that can be exploited in the code, it highlights that and gives you recommendations on that. It gives you ideas on how to fix that.

We have a more secure code because it is based on top security standards. Before we moved to Fortify SAST, we already had code running in production. When we moved to Fortify SAST, we had to rescan our code running in production. We got more and more vulnerabilities, which made people upset, but overall, our security was enhanced. It also enhanced the knowledge of our developers. Our developers are learning more. Many developers were frustrated in the beginning because there were many vulnerabilities, but as time went on, they liked its features. They find it straightforward now. They read about it, and they can fix their code easily. Without any back-and-forth communication, they can find the line, the recommendation, and what to do about it in one place. That is awesome.

Fortify Software Security Center gives a good overview of how the application is implemented, but it is not a 360-degree view. Sometimes we have false positives, and sometimes, it does not catch the design flows. It will mark something as vulnerable because it does not have the full picture. The highlighted code might be a part of another module, so it cannot see the full picture, but it is a very good tool. It is better than the ones we had before.

I have not yet used Fortify Software Security Center for managing and tracking risks associated with the open-source components used in our software project. We recently started to use Fortify SAST and are still exploring and discovering things. We usually do that through Sonatype Nexus, but I have seen it catching vulnerabilities. Some users have scanned the library by mistake, and I have seen it catching vulnerable code in the library. It points out why we wrote the code this way, and the code should have been that way. If there is a variable that has a sensitive name, such as a key, password, or something else, it catches that. After we have integrated it with Sonatype, we will have more exposure, but we are not yet at that stage.

I really like Fortify Software Security Center. We can scan the code and push the results. I can also see all the applications. I know the portfolio of the applications that we have. I can see all the information about the organizations, the code, and the developers in one spot. It is good for the management and also for the development teams. If their supervisors want to know the security status of their applications, they can go there straight away and check that information. It is very good in this aspect.

Fortify SAST has helped in the remediation of potential vulnerabilities by using accurate and reliable results. I like that they use standards such as OWASP Top 10 or SANS Top 25. They are very good at this. When it finds any vulnerabilities, it shows you by the rank. You can filter by so many standards. It gives you a description of the vulnerability as well as recommendations on how to fix it. It also gives you some references if you want to read more. It is very good.

Fortify SAST has helped a lot to enable developers to build secure code from the start. We have many developers. They have the development skills, but they do not have security skills. Now, there is something that tells them how to write the code properly. For instance, they use a function, and then they get the recommendation to use another function. They do not know the other function. They go ahead and use it, and the code still runs as before, but it is safer. With time, people avoid these issues. It is like a spelling checker. You get recommendations while writing the code.

Fortify and Sonatype solutions help to maintain compliance with applicable regulations. Fortify SAST is built on top of very high standards such as OWASP Top 10, SANS Top 25, PCI DSS, etc. These are very repeatable security standards. It includes over a thousand vulnerability categories. It covers a lot of vulnerabilities.

Fortify SAST helps us reduce our risk exposure on applications through the discovery of vulnerabilities and weaknesses. They have something called rulepacks that are the guidelines. There are rulepacks for different languages. They are the security standards that the code will follow. These rulepacks are updated frequently by the Fortify team themselves, and we just have to feed them into Fortify Software Security Center so that it has updated information about vulnerabilities, and it can discover more. The more you discover and fix, the more secure and resilient code you will have.

Fortify SAST provides real-time feedback on security issues. When you scan, you get the results instantly. Sometimes, for certain code languages, it takes a little more time to scan, which can be frustrating, but it provides real-time feedback. You get a small description, and you also have the details. There is one tab for recommendations, and there is also a tab for references.

We recently had this activity where we wanted to integrate the tool with a pipeline. We are using Azure DevOps, and we managed to integrate that. It was straightforward. You get a plugin or an extension, and the code is pushed and scanned, and you get the results. It is straightforward. I can see it functional for such deployments. We are ready for the cloud and automation, but we are still in the testing phase.

Fortify SAST has helped free up our staff for other projects or tasks. Because it is very informative and clear, we have a lot fewer issues for which people come back to us. They come back to us if they think it is a false positive or if they need a waiver because they cannot fix it due to some limitations, but in the majority of cases, they can control and learn, and they can do it on their own. It helped us a lot in this aspect, but I do not have the metrics. We have been using it only for a few months, and we have a shortage of people. It has saved the communication time that we were spending on emails and reporting. We now have less of that. We all go to one place. Instead of sending me an email or having a phone call, developers now go to Fortify Software Security Center and put in what they think. For example, they will say that it is a false positive because of this and that. They will send it to me, and I will go to Fortify Software Security Center. I will read it and review it, and if I find it okay, I will give the go-ahead to get rid of it. Otherwise, we would need more discussion. It improves communication big time for me.

We use Fortify SAST to scan our code. It is used for the static code and not the running code. It finds vulnerabilities, and it finds bad practices. If you are using something that can be exploited in the code, it highlights that and gives you recommendations on that. It gives you ideas on how to fix that.

We have a more secure code because it is based on top security standards. Before we moved to Fortify SAST, we already had code running in production. When we moved to Fortify SAST, we had to rescan our code running in production. We got more and more vulnerabilities, which made people upset, but overall, our security was enhanced. It also enhanced the knowledge of our developers. Our developers are learning more. Many developers were frustrated in the beginning because there were many vulnerabilities, but as time went on, they liked its features. They find it straightforward now. They read about it, and they can fix their code easily. Without any back-and-forth communication, they can find the line, the recommendation, and what to do about it in one place. That is awesome.

Fortify Software Security Center gives a good overview of how the application is implemented, but it is not a 360-degree view. Sometimes we have false positives, and sometimes, it does not catch the design flows. It will mark something as vulnerable because it does not have the full picture. The highlighted code might be a part of another module, so it cannot see the full picture, but it is a very good tool. It is better than the ones we had before.

I have not yet used Fortify Software Security Center for managing and tracking risks associated with the open-source components used in our software project. We recently started to use Fortify SAST and are still exploring and discovering things. We usually do that through Sonatype Nexus, but I have seen it catching vulnerabilities. Some users have scanned the library by mistake, and I have seen it catching vulnerable code in the library. It points out why we wrote the code this way, and the code should have been that way. If there is a variable that has a sensitive name, such as a key, password, or something else, it catches that. After we have integrated it with Sonatype, we will have more exposure, but we are not yet at that stage.

I really like Fortify Software Security Center. We can scan the code and push the results. I can also see all the applications. I know the portfolio of the applications that we have. I can see all the information about the organizations, the code, and the developers in one spot. It is good for the management and also for the development teams. If their supervisors want to know the security status of their applications, they can go there straight away and check that information. It is very good in this aspect.

Fortify SAST has helped in the remediation of potential vulnerabilities by using accurate and reliable results. I like that they use standards such as OWASP Top 10 or SANS Top 25. They are very good at this. When it finds any vulnerabilities, it shows you by the rank. You can filter by so many standards. It gives you a description of the vulnerability as well as recommendations on how to fix it. It also gives you some references if you want to read more. It is very good.

Fortify SAST has helped a lot to enable developers to build secure code from the start. We have many developers. They have the development skills, but they do not have security skills. Now, there is something that tells them how to write the code properly. For instance, they use a function, and then they get the recommendation to use another function. They do not know the other function. They go ahead and use it, and the code still runs as before, but it is safer. With time, people avoid these issues. It is like a spelling checker. You get recommendations while writing the code.

Fortify and Sonatype solutions help to maintain compliance with applicable regulations. Fortify SAST is built on top of very high standards such as OWASP Top 10, SANS Top 25, PCI DSS, etc. These are very repeatable security standards. It includes over a thousand vulnerability categories. It covers a lot of vulnerabilities.

Fortify SAST helps us reduce our risk exposure on applications through the discovery of vulnerabilities and weaknesses. They have something called rulepacks that basically are the guidelines. There are rulepacks for different languages. They are the security standards that the code will follow. These rulepacks are updated frequently by the Fortify team themselves, and we just have to feed them into Fortify Software Security Center so that it has updated information about vulnerabilities, and it can discover more. The more you discover and fix, the more secure and resilient code you will have.

Fortify SAST provides real-time feedback on security issues. When you scan, you get the results instantly. Sometimes, for certain code languages, it takes a little more time to scan, which can be frustrating, but it provides real-time feedback. You get a small description, and you also have the details. There is one tab for recommendations, and there is also a tab for references.

We recently had this activity where we wanted to integrate the tool with a pipeline. We are using Azure DevOps, and we managed to integrate that. It was straightforward. You get a plugin or an extension, and the code is pushed and scanned, and you get the results. It is straightforward. I can see it functional for such deployments. We are ready for the cloud and automation, but we are still in the testing phase.

Fortify SAST has helped free up our staff for other projects or tasks. Because it is very informative and clear, we have a lot fewer issues for which people come back to us. They come back to us if they think it is a false positive or if they need a waiver because they cannot fix it due to some limitations, but in the majority of cases, they can control and learn, and they can do it on their own. It helped us a lot in this aspect, but I do not have the metrics. We have been using it only for a few months, and we have a shortage of people. It has saved the communication time that we were spending on emails and reporting. We now have less of that. We all go to one place. Instead of sending me an email or having a phone call, developers now go to Fortify Software Security Center and put in what they think. For example, they will say that it is a false positive because of this and that. They will send it to me, and I will go to Fortify Software Security Center. I will read it and review it, and if I find it okay, I will give the go-ahead to get rid of it. Otherwise, we would need more discussion. It improves communication big time for me.

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.

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

One of the ways it has improved the way our organization functions is that it has created awareness of unlicensed, third-party dependencies and insecure vulnerabilities. That's what it has done at the moment. It's going to have a bigger impact when we start enforcing it on the build pipeline. Then they will be at a point whereby they have to conform to the policy.

There are a number of open-source components that it has highlighted. It means that we have to find a replacement for them. There's a recommendation that's given when it highlights them. So we can remain in the same open-source components, it's just that there has been a patch or an update to them to close off vulnerabilities.

In the context of remediation costs, there is the issue of reputation if you are not releasing secure apps to market. That's one major problem. Secondly, if you know you're releasing insecure applications, you're incurring technical debt because you're going to have to, at some point, mitigate those security vulnerabilities.

It's become a mandatory control now. We just went through a process of defining all the DevOps controls, and one of those controls is to use Nexus IQ. They can't skip that part of their build pipeline. Every code has to be scanned.

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.

Without it we didn't have any way to detect vulnerabilities except through reactive measures. It's allowed us to be proactive in our approach to vulnerability detection.

Sonatype has also brought open-source intelligence and policy enforcement across our SDLC. It enforces the SDLC contributors to only use the proper and allowed libraries at the proper and allowed time in the lifecycle of development. The solution blocks undesirable open-source components from entering our development lifecycle. That's its whole point and it does it very well.

We use the solution to automate open-source governance and minimize risk. With our leaders across our different organizations, we set policies that govern what types of libraries can be used and what types of licenses can be used. We set those as settings in the tool and the tool manages that throughout the lifecycle, automatically.

It's making things more secure, and it's making them higher in quality, and it's helping us to find things earlier. In those situations where we do find an issue, or there is an industry issue later, we have the ability to know its impact rapidly and remediate more rapidly.

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. 

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

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

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

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.

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. 

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.

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

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

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

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

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

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

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

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

Previously, the developers would do their work and then it would be evaluated using something called penetration testing. With the results of the penetration testing they would go back and make changes, and then we would have to do the penetration testing again. That was a very long-winded process, whereas now, they can develop with confidence knowing that the libraries and binaries that they are using have already passed penetration testing. That saves a lot of time in the lifecycle. It's difficult to even quantify because it's so huge. But we're talking about reducing the development lifecycle by about 90 percent, minimum.

It has helped developer productivity. It's like working in the dark and all of a sudden you've got visibility. You can see exactly what you're using and you have suggestions so that, if you can't use something, you've got alternatives. That is huge.

It's been pretty good. I'm the one who has to un-quarantine things, but the false-positive rate is not too bad, or else I'd be doing that all day. From that point of view it's been good.

The solution enables us to manage and secure the component part of our software supply chain. That is done between the policies, their data, and configuring. You have to make sure everybody's actually pointing to the repo. We started talking about blocking public repos from within the networks, so that would force people to go through the solution, but we haven't quite gotten there yet. However, we have definitely have a lot of people going through the repo. We can see how many components are cached and how many are quarantined. We have definitely had 1,000 or more components quarantined during our use of the product. That's all technical debt we would have accrued if we hadn't been using it.

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

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

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

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

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

The solution has improved the way our company functions in terms of the way that developers think about the components that are being built into their products, making sure they're not being duplicated, for example. The developers now understand that there's a cost associated with including open-source. It may not have a licensing fee, but there is a cost associated with it. That sort of education piece has had a big influence.

It has also brought open-source intelligence and policy enforcement across our SDLC. As the teams are setting up their development environments, we have now gotten them to build Sonatype into their development pipeline. They scan their codebase so they actually catch things at the point that they introduce new, open-source software into the products, to make sure they're not actually introducing vulnerabilities or licensing-policy breaches.

Sonatype has also reduced our risk in releasing secure apps to market. Previously, teams would just release without knowing what risks it was exposed to. Now, we can actually do a better risk assessment.

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

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

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

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

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

We have increased the digital footprint of our company over the last few, extensively. We have extensive open source development happening which depend on open source components. Using the scanning with Nexus IQ, a lower count of false positives has helped us roll out our security policies across the development cycle and ensure that our deployments to production are as secure as possible. This helps us avoid critical vulnerabilities being exposed onsite. It saves us time in any remediation activities that we may had after deployment, because if we had discovered security issues after the application was completely developed and deployed, it would be more difficult to go back and make changes or put it back into a cycle. Then, we would have to shift to multiple outcomes due to business expectations, member expectations, and our client expectations. Bringing it back into the development cycle would take a lot of time. Attaching it to the development cycle and by integrating Nexus IQ into our plans, we have a policy that will not allow vulnerable artifacts to be deployed to production. This forces it to be handled during the development cycle.

The solution has increased developer productivity when remediating issues, as the issues are clearly laid out. We are saving five to 10 percent in developer productivity. 

This solution integrates well with our existing DevOps tools. We use it in our Jenkins build pipeline. If the Nexus IQ scan fails, then it produces an error that fails the build. When a developer builds on their machine, as well, it flags issues and lets them know which component has a problem.

This solution brought open source intelligence and policy enforcement across our SDLC (software development lifecycle). The enforcement is simply because the build pipelines use Nexus IQ, then it fails when Nexus IQ has an error and identifies a component with multiple security issues because it breaks the release pipeline. The enforcement is there because you can't release anything without going through that pipeline.

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

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

We can automate the pipeline of CI/CD. For example, if a publication uses an open source library and it's vulnerable, then the security team will mark it in the Lifecycle suite and it can go through the pipeline without manual interaction by the developer.

I'm not a security guy but I have sat with the security team. Once you set the policies, you wont need to change them. The policies wouldn't change that frequently. It covers the needs that we have.

Using the solution we have been able to clean our environment, providing more protection for our applications. We have a more hygienic environment than before. Before using Lifecycle we were almost blind to whatever we had and didn't look into the vulnerabilities within open source libraries. Now we do.

It has helped to increase our productivity a lot, especially with Nexus Repository Manager. It is way more agile. There is no comparison between our productivity before and now.

In terms of the accuracy of the data from Sonatype, at first the teams were challenging whatever the solution provided, but they then verified with the vendor of the open source libraries or via the related community, and they realized that the data from Sonatype is something that is done carefully. It's accurate and valid data. We are now introducing a security layer for open source. Before, there was no security on open source and they did whatever they wanted but that is no longer the case. They have to fix things before deploying them. It helps them resolve issues. It works most of the time, but sometimes there are challenges for the developer in solving them.

We also use the solution to automate open source governance and minimize risk with policies. Some of our developers, although not all of them, have their own Jenkins installed and they set rules and policies. They have integrated Jenkins with Lifecycle and, whenever they push into production, it verifies they are not violating any policies. Once everything is smooth, it goes into production. We haven't formalized that process yet.

Before, we had open-source Nexus Repository, but with Lifecycle we have Nexus RM and IQ Server as well and we can scan .jars. In addition, we have the plugins for individual developers, which benefits us and the developers when they introduce a new artifact into their applications. It helps them identify what are potential risks and defects. They can resolve them right there and proceed there with their development.

It also brings intelligence to the open-source artifacts, because intelligent servers scan all the vulnerabilities, identify the problems, and then we can ask the individual teams to fix them. That is a plus.

The solution blocks undesirable open-source components from entering our development lifecycle. There are certain .jars which we can block.

In terms of open-source governance, the tool tells us all the threats that are out there in the public sector repositories, threats which, potentially, no one knows. We get to know them and we can use the tool to let other people know which direction to go in.

The solution has improved the time it takes us to release secure apps to market by at least 50 percent. It has also increased developer productivity to some extent because of the plugin which is included for the IDE. It gives a report of the vulnerabilities. It does save time in figuring out the right open-source versions that we need to use. It has helped improve the productivity of the developers by about ten percent.

For the application onboarding, we are focusing on automating that as much as possible. Considering the amount of applications that we scan, it's probably not feasible to do all that within the GUI, but the APIs provided by the solution are really good. We have some positive impressions for that. The automatic onboarding seems to work quite well.

One thing we recently did is we automatically onboarded every application that we deployed to production. We scanned each one of them and now have a complete picture of our estates. Every single vulnerability introduced from an open source component is now visible, and we have a clear number. That number was big. Really, we have a lot of issues which we were unaware of. We suspected that we had them, but we now have a clear number that makes selling the solution internally a lot easier.

The solution brought open source intelligence and policy enforcement to a small extent across our SDLC (software development lifecycle) because we have only fully rolled it out in a small number of teams. However, where we did do this, we have started scanning right at the built face, seeing issues really early in the lifecycle.

The solution automates open source governance and minimizes risk. We are trying to reduce the amount of vulnerabilities that we introduce using open source codes. The entire goal of why we're doing this solution is to have it in the lifecycle of our software development and reduce risk.

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

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

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

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

We rely on the default policies because we are new to the system. We haven't adjusted any policies and are sticking with whatever policies were shipped to us. We are mostly focused on policies 9 and 10 for the highest threat levels. These are the ones which we are focusing right now. We don't want to make any modifications or adjustments in terms of 9 or 10. Mostly, it will be the security officer's decision if we need to update the policies. I'm the manager of the development team and my developers usually will not make any changes in terms of policies.

It provides a very detailed analysis of our library. Then, when some of the scans identify a licensing issue, we look at them and know if we have the license. It sort of scans everything. Without this tool, I don't think that there's even a capability to go through all these libraries, because some of the libraries were introduced by contractors and a developer who no longer works here anymore. When Nexus comes in with its scans, it reports on licensing or other vulnerabilities. This is easier to do instead of asking around.

It gives alerts for new vulnerabilities before our clients do, so we have time to review them, audit them, and determine how we need to proceed with resolving the issues before we get any client communication.

Before we had this in place, we had a much more reactive approach to CVE listings.   Since integrating this, and as we've refined our process over the past eight months or a year, we have moved to a proactive approach allowing auditing and decisions on mitigation before any incoming client submissions.

In addition, it has brought open-source intelligence and policy enforcement across our software development lifecycle. As a component of the lifecycle, it gives us more controls in place. As far as bringing in dependencies goes, we're able to see what a dependency is introducing, from a security and licensing perspective, before we publish a release to the public. So within the build stage, if we pull in a new dependency, Nexus will very quickly tell us whether it has issues or not. And we catch it. It scans in the build stages; we have it checking our staging where we're doing our regression; and it's also monitoring our released branches and letting us know if issues are found in our releases. It really does hit all stages of that lifecycle.

It has only improved things very little because, for now, we use the reports from IQ to improve the libraries, but it doesn't yet have enough coverage.

It has helped to enforce open-source intelligence and policies across our software development lifecycle, mainly by automating controls that we had put in place before. It has helped to enforce things. It has blocked some open-source components or, more accurately, raised warnings about them. It's not a blocker in our system because, for now, it's only implemented as an informative system.

The solution has also improved the time it takes to release secure apps to market. We have been able to replace homemade scripts, which took a few hours to create, by very much simpler workflows provided natively by Nexus, which are working in a few minutes, or tens of minutes. It has saved us about 40 percent, in terms of time. But more than the duration, it's helpful that we don't have to maintain or make scripts. That's the most important thing.

It has improved developer productivity and accuracy. That happened a long time ago because we have been using it for so long, but as soon as we deployed the Nexus solution in the company, people didn't need to locally build a lot of stuff. So we were much more easily able to work together, to collaborate, and consume other teams' products. That was a long time ago, but it was definitely an important step.