Previously used Burp Suite, OWASP Zed Attack Proxy, Python scripts / Powershell and Batch, Retire.JS, Vulners, and Wappalyzer browser plugins.
Application Security Plugin Reviews
Showing reviews of the top ranking products in Application Security, containing the term Plugin
reviewer1436241 says in a Veracode review
DevSecOps Consultant at a comms service provider with 10,001+ employees
There are quite a few features that are very reliable, like the newly launched Veracode Pipelines Scan, which is pretty awesome. It supports the synchronous pipeline pretty well. We been using it out of the Jira plugin, and that is fantastic.
We are using the Veracode APIs to build the Splunk dashboards, which is something very nice, as we are able to showcase the application security hygiene to our stakeholders and leadership.
We have been using Veracode Greenlight for the IDE scanning.
Veracode has good documentation, integrations, and tools, so it has been a very good solution.
Veracode is pretty good about providing recommendations, remedies, and guidelines on issues that are occurring.
It is an excellent solution. It finds a good number of the securities used, providing good coverage across the languages that we require at our client site.
We have been using the solution’s Static Analysis Pipeline Scan, which is excellent. When we started, it took more time because we were doing asynchronous scans. However, in the last six months, Veracode has come with the Pipeline Scan, which supports synchronous scans. It has been helping us out a lot. Now, we don't worry when the pentesting report comes in. By using Veracode, the code is secure, and there are no issues that will stop the release later on in the SDLC.
The speed of the Pipeline Scan is very nice. It takes less than 10 minutes. This is very good, because our policy scans used to take hours.
Veracode is good in terms of giving feedback.
Usually, we open tickets now using the JIRA/GitHub integration and then we plan them. We decide when we want to fix them and we assign them to developers, mostly because there are some projects that are a little bit more on the legacy side. Changing the version of the library is not easy as in the newer projects, in terms of testing. So we do some planning. But in general, we open tickets and we plan them.
We also have it integrated in the pipelines, but that's really just to report. It's a little bit annoying that the pipeline might break because of security issues. It's good to know, but the fact that that interrupts development is not great. When we tried to put it as a part of the local build, it was too much. It was really getting in the way. The developers worried that they had to fix the security issues before releasing. Instead, we just started creating the issues and started doing proper planning. It is good to have visibility, but executing it all the time is just wrong, from our experience. You have to do it at the right time, and not all the time.
The solution integrates with developer tools, if you consider JIRA and GitHub as developer tools. We tried to use the IntelliJ plugin but it wasn't working straightaway and we gave up.
We haven't been using the container scanning of Veracode, mostly because we are using a different product at the moment to store our Docker images, something that already has some security scanning. So we haven't standardized. We still have to potentially explore the features of Veracode in that area. At the moment we are using Key from IBM Red Hat, and it is also software as a service. When you upload a Docker image there, after some time you also get a security scan, and that's where our customers are getting our images from. It's a private registry.
Overall, I would rate Veracode as a five out of 10, because the functionality is there, but to me, the usability of the user interface is very important and it's still not there.
The static code analysis, which is integrated into the CI/CD environment, is a valuable feature. We get quick results of what has gone into the environment in terms of any vulnerability in the code and for the Eclipse plugins of Veracode. This is one of the more valuable features because a developer can get a sense at the line level if there are any issues.
The most valuable feature is actually the support provided by Veracode. Once you start to use the platform, you can mount the IDE plugin for your script. The advantage is that you can run the scan and check what the problem is and you can fix it yourself. Support could be used to address something that could go beyond your skills. If you use Veracode Greenlight, you have a small pop-up that you can use to interact directly with the team and you can ask a consultant to advise how an issue can be fixed. One of the good things about the Greenlight plugin is that it is very simple. There are several guides that tell you how to install it. It's a matter of one or two minutes and you are ready to go.
Once you check something, they provide links, not manually, it's all automated. When you want to check into a vulnerability you click and open the website where there is a description. If this is not enough of an answer, you can ask directly by scheduling an appointment with a Veracode guy.
Another feature of Veracode is that they provide e-learning, but the e-learning is not basic, rather it is quite advanced. They don't teach you how to develop in Java, Python, PHP or C#, but they instruct you about the best practices that should be adopted for secure code developing and how to prevent improper management of some component of the code that could lead to a vulnerability. The e-learning that Veracode provides is an extremely good tool. And as far as I know, there are no other competitors that offer it.
The best stuff is the training: this enables your team to adopt the same programming approach, although these people have a different background or joined the projects in a different phase. Doing that, they can take the training and be aligned so that they all write code in a good way.
We also use the Static Analysis Pipeline Scan and it's quite good. They provide several of the most common templates for pipelines. You see the process, while you program, right up until you package an application, and that the platform is able to detect things that are a blocking point. Before deploying to the production, you already know what is doing. And the speed of the Pipeline Scan is quite good.
Another good feature is the policy reporting for ensuring compliance with industry standards and regulations. We test compliance for medical devices, for GDPR, and for payment methods. These are all good. If you are not correctly prepared on one of these sets of regulations, you know that Veracode is going to take care of it using pre-prepared templates. But we can also customize our own policy if we are facing a unique use case. Even if it's not really common, we can take a regulation and build it the way we want it to look.
In addition, you can check everything from the dashboard. Veracode provides a web portal that is connected with your account and through that you can check the status of all the deployments that were run. And suppose you also have an application that is quite complex. You can deploy and upload it through the portal. When it is ready, you receive a notification from the portal that the job has been done and that you can check the results. When you go to the dashboard, you have the OWASP vulnerabilities. There is a really simple graphic with the colors showing how many vulnerabilities have been found and how much these vulnerabilities are repeated in your code. It also tells you the potential effect, if it is a backdoor data breach, for example, etc. It also suggests what you can do to remediate. It might suggest modifying code or changing the status of some part of the development, or updating a third-party.
And if you have people on different projects, there is also a role management feature, so you can select, for example, that people who are working on a given project can only see that project. If you are running something with different levels of classifications, for example, if you have an external consultant, it does not affect the confidentiality of the system. When people are collaborating, not all people are at the same level of an NDA. It is good that each person can see only their part implementing Need-To-Know.
It also integrates with developer tools. We use IntelliJ and Eclipse, among others.
The ideal situation in terms of putting the results in front of the developers would be with Veracode integration into the developer environment (IDE). They do have a plugin, which we've used in the past, but we were not as positive about it. The pricing model was expensive and the results were not the same as the full solution analysis. It gives a differently scoped "just in time" analysis within the context of the IDE, so it didn't speak to the same problem space.
The best situation would be the one where the developers don't even need to log into the web portal, and the results from the scans would be delivered into their IDEs. It would be an asynchronous job, but if they could see the results right there, while they're working on the code, then they wouldn't need to go to a separate tool to look at the information to figure out what to do next.
The workflow today on the build side is optimal, so imagine that's still doing the same thing but then in the backend, whenever a developer has that project open in the browser, if they chose to, they could enable a view to see the most recent Veracode results of that module. That scan might be from last night or six hours ago or any other point, and that's fine. It would be the best possible situation to put the results and the actions right in front of the developer, in the tool that they're already using when they're touching the code.
The only other thing that we've found a reasonable workaround with is how to work with microservices in the context of Veracode. This was necessary because Veracode's licensing model and the interaction model are built around an idea of an application. When you're talking about a section of business logic that's being delivered by possibly dozens of microservices, there is some friction with Veracode in terms of how that application gets defined and how the scans occur and get reported on.
When we reached out to Veracode about this, I got a slide deck that provided us with different options of how they recommend proceeding in this context. It was helpful, and clearly a question they've considered and they had answers ready to go on. The ideas helped us and essentially reinforced what we were already thinking. It's getting the job done, but it still feels like a little bit of a square peg in a round hole and it could be a little smoother in terms of that interaction.
The problem boils down to how we fit the microservices architecture into the Veracode notion of an application. We need to be able to get a holistic view across the microservices, which is extremely challenging, especially when those microservices are owned by different teams who have different needs to see and respond to the scans.
Qualys Web Application Scanning: Plugin
reviewer1387992 says in a Qualys Web Application Scanning review
Senior Software Developer at a tech vendor with 1,001-5,000 employees
Because of tasking, the initial setup is very straightforward. We didn't have to purchase any hardware for the installation. It is task-based. The cloud provision is there. It is good. I think nowadays everyone is going with the cloud provisioning. That way you can subscribe for any number of years to use the software.
I think the initial setup took a couple of hours because there were no plugins and nothing to be installed.
PortSwigger Burp Suite Professional: Plugin
There are a lot of good features and the most valuable one varies depending on what test you are performing. They are also consistently improving and releasing new features.
Two of the most valuable features are the Extender Tab and Repeater.
With the Extender Tab, if you know how to code then you can create a plugin and add it to Burp. It's not limited to their features because we can always add or do some customization of the features.
Even if you don't know how to code, there are hundreds of third-party plugins that are available to extend the features of the product. Some of them are open-source and there are some that are provided by Burp.
The user interface is good, having been changed within the past two years.
It's an amazing tool. We can work with it automatically, or we can work with it manually.
There is no other tool like it. I like the intuitiveness and the plugins that are available.
The plugins are similar to integration. I can create my own login and use it.
reviewer1552449 says in a PortSwigger Burp Suite Professional review
Application Security Architect at a logistics company with 10,001+ employees
I have found the best features to be the performance and there are a lot of additional plugins available.
I have found this solution has more plugins than other competitors which is a benefit. You are able to attach different plugins to the security scan to add features. For example, you can check to see if there are any payment systems that exist on a server, or username and password brute force analysis. You are able to do many different types of scans, such as SQL injection. There are a lot of deep packages analyzing functions that make this solution have more usability.
Netsparker by Invicti: Plugin
reviewer1403718 says in a Netsparker by Invicti review
Lead Security Architect at a comms service provider with 1,001-5,000 employees
There are different products in the market for DAST like Micro Focus, IBM AppScan, Acunetix, and Burp Suite. All these products have their pros and cons. Netsparker is really good, and it has a vast variety for security checks, plugins, that could be used for finding vulnerabilities.
reviewer1390020 says in a SonarQube review
Engineer at a pharma/biotech company with 201-500 employees
The library could have more languages that are supported. It would be helpful.
There are a few clauses that are specific to our organization, and it needs to improve. It's the reason that were are evaluating other solutions. It creates the ability for the person who releases the authorized release, which is not good. We would like to be able to expand on our work.
MicroFocus, as an example, would be helping us with that area or creating a dependency tree of the code from where it deployed and branching it into your entire code base. This would be something that is very helpful and has helped in identifying the gaps.
It would be great to have a dependency tree with each line of your code based on an OS top ten plugin that needs to be scanned. For example, a line or branch of code used in a particular site that needs to be branched into my entire codebase, and direct integration with Jira in order to assign that particular root to a developer would be really good.
Automated patching for my library, variable audience, and support for the client in the CICD pipeline is all done with a set of different tools, but it would be nice to have it like a one-stop-shop.
I would like to see improvements in defining the quality sets of rules and the quality to ensure code with low-performance does not end up in production. We would also need the ability to edit those rules.
We had to contact technical support back several years ago because we had an issue with one of the new SQL plugins which ended up being resolved. The support is not required anymore because they have very good documentation that meets our needs.
It's convenient due to the fact that it's open-source.
We're able to identify bugs and those kinds of things before we actually push anything into a staging or production area. It helps our developers work more efficiently as we can identify things in a code prior to it being pushed to where it needs to go. It's a great little loop. You see this, fix it, take it back. Versus, putting something into an environment and then everything is all broken. It's a good development test tool.
Nowadays you can add extensions, similar to what you can do with the Jenkins tool, the CICB tool, the build tool. Jenkins can have a lot of plugins that interface with a lot of vendors or it can do a lot of things. Just like Google Chrome where you can bring in an extension, you can do the same here. In SonarQube, you can add something by just adding an extension that you may have to pay extra for, However, that add-on has additional functionality that the base software may not necessarily have in its core.
For example, Fortify has some kind of special capability that they have for checking and SonarQube has created an extension that allows the Fortify extensions. Right now, I have Fortify, however, it's in this product at a very modular level.
SonarQube can be used to analyze application code. We are testing SonarQube with some of our other products. We use the Sonar Link plugin with Teamscale, which is then applied to the main product we are using.
reviewer1689996 says in a SonarQube review
Software Engineer at a tech services company with 11-50 employees
The software testing tool capability could improve. It does not always integrate well. You have to use a specific plugin and the plugin does not always go in Apple's applications.
In the next release, they should add the ability to analyze containers.
reviewer1023003 says in a SonarQube review
Development Team Lead at a financial services firm with 1,001-5,000 employees
Our primary use case of SonarQube is getting feedback on code. We are using Spring Boot and Java 8. We are also using SonarLint, which is an Eclipse IDE plugin, to detect vulnerabilities during development. Once the developer finishes the code and commits the code into the Bitbucket code repository, the continuous integration pipeline will automatically run using Jenkins. As part of this pipeline, there is a build unit test and a SonarQube scan. All the parameters are configured as per project requirements, and the SonarQube scan will run immediately once the developer commits the code to the repository. The advantage of this is that we can see immediate feedback: how many vulnerabilities there are, what the code quality is, the code quality metrics, and if there are any issues with the changes that we made. Since the feedback is immediate, the developer can rectify it immediately and can further communicate changes. This helps us with product quality and having less vulnerabilities in the early stages of development.
This solution is deployed on-premise.
I would like to see integration with popular IDEs, such as Eclipse. If Coverity were available as a plugin then developers could use it to find security issues while they are coding because right now, as we are using Coverity, it is a reactive way of finding vulnerabilities. We need to find these kinds of problems during the coding phase, rather than waiting for the code to be analyzed after it is written.
Varun V says in a Coverity review
Senior Solutions Architect at a computer software company with 11-50 employees
I used CodeSonar a few years back. Both tools have their advantages. In any static analysis tool, the first stage is the instrumentation of the source code. It'll try to capture the skeleton of your source code. So when I compare them based on the first phase alone, Coverity is far better than CodeSonar.
They both use a similar technique, but CodeSonar uses up way more storage resources. For example, to scan a 1GB code base, CodeSonar generates more than 5GB of instrumented files for every 1GB of code base. In total, that is 6GB. Coverity generates 500MB extra on top of 1GB, so that equals 1.5GB all in. That's a huge difference. CodeStar would eat up my disc space and hardware resources when I used it, whereas Coverity is minimal.
In terms of checkers, both CodeSonar and Coverity cover a good length and breadth, especially for C and C++ programming languages. But CodeSonar focuses only on four languages—C, C++, Java, and C#—only four programming languages, whereas Coverity supports more than 20-plus programming languages.
Also, the two are comparable with respect to their plugin offerings, but there are crucial differences. For example, CodeSonar only focuses on well-known integrations, like Jenkins and JIRA, but you cannot expect all customers to use the same tools. Coverity supports almost all CI/CD tools, including Jenkins and Bamboo. It also integrates with service providers like Azure DevOps Pipelines, AWS CodePipelines that CodeSonar hasn't added yet. The plugins are available in the marketplace, and you don't have to pay extra. You just have to download it from the marketplace, hook the plugin in your pipeline, and ready to use kind of approach. So these are some of the major use cases, three major use cases I would say when you compare apples to apples with CodeSonar and Coverity.
Fortify Application Defender: Plugin
The biggest complaint that I have heard concerns additional platform support because right now, it only supports applications that are written in .NET and Java. They need better support for applications written in Python or more advanced web service-type implementations. Better support for other architectures is critical.
Technical support needs to be improved.
It would be helpful to include agent deployment as part of the Azure DevOps marketplace. This would make it really easy for customers to get this plugin and install it within their application centers.
Sonatype Nexus Lifecycle: Plugin
reviewer1268016 says in a Sonatype Nexus Lifecycle review
IT Security Manager at a insurance company with 5,001-10,000 employees
The key feature for Nexus Lifecycle is the proprietary data they have on vulnerabilities. The way that they combine all the different sources and also their own research into one concise article that clearly explains what the problem is. Most of the time, and even if you do notice that you have a problem, the public information available is pretty weak. So, if we want to assess if a problem applies to our product, it's really hard. We need to invest a lot of time digging into the problem. This work is basically done by Sonatype for us. The data that it delivers helps us with fixing or understanding the issue a lot quicker than without it.
The solution integrates well with our existing DevOps tools. We have a few different ways of integrating it. The primary point is the Jenkins plugin to integrate it into the pipeline, but we also use the API to feed applications from our self-developed systems. So, the Sonatype API is very valuable to us as well. We've also experimented with IDE plugins and some other features that all look very promising.
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.
The REST API is the most useful for us because it allows us to drive it remotely and, ideally, to automate it.
We have worked a lot on the configuration of its capabilities. This is something very new in Nexus and not fully supported. But that's one of the aspects we are the most interested in.
And we like the ability to analyze the libraries. There are a lot of filters to output the available libraries for our development people and our continuous integration.
The solution integrates well with our existing DevOps tools. It's mainly a Maven plugin, and the REST API provides the compliance where we have everything in a giant tool.
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."
reviewer1380810 says in a Sonatype Nexus Lifecycle review
Computer Architecture Specialist at a energy/utilities company with 10,001+ employees
We ran into too many debates and there was this culture of "security is not mine" and someone else should have to deal with it. After using the solution, they realized this is not the case. Security vulnerabilities had to be addressed. I was a developer and I understood their complaints, but security is important and you have to go with it. The tool is there to automate and simplify your work and you should utilize it. It has been a very good experience.
We are introducing Lifecycle and developers will be aware, with the IDE plugin, from the beginning, whether whatever libraries they are using are vulnerable or not. There should be no delays if they work with it from the beginning.
It is used, or should be used, by all of our 120 developers. But in a group developing a given application, not everyone would commit to it and scan the application. One would do the scanning. But, overall, all of them should be directly or indirectly using it or depending on it.
When we move it to production we will need to do a recertification of the users and find out who is not using it, who would use it, and who is shifting to other organizations. Then we will decide on the number.
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.
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.
I wasn't involved in the server installation. From my point of view, the deployment was quite easy. The servers were set up—a test instance and a production instance. In the test instance, we can play around and see if everything is working.
The IDE integration was quite easy because you just have to download the plugins and then set up the URL and the user and password. With Jenkins, we had to play around a little bit, but it was not that tricky. The integration is really nice because the plugins work quite well.
Reviewer636936 says in a Snyk review
Information Security Engineer at a financial services firm with 1,001-5,000 employees
If the Snyk had a SAST or DAST solution, then we could have easily gone with just one vendor rather than buying more tools from other vendors. It would save us time, not having to maintain relationships with other vendors. We would just need to manage with one vendor. From a profitability standpoint, we will always choose the vendor who gives us multiple services. Though, we went ahead with Snyk because it was a strong tool.
Snyk needs to support more languages. It's not supporting all our languages, e.g., Sift packages for our iOS applications. They don't support that but are working to build it for us. They are also missing some plugins for IDEs, which is the application that we are using for developers to code.
There are a couple of feature request that I have asked from Snyk. For example, I would like Snyk to create a Jira ticket from Slack notifications. We already have Snyk creating a pull request from Slack notifications, so I asked if we could create a Jira ticket as well so we can track the vulnerability.
It is a fairly developer-focused product. There are pretty good support and help pages which come with the developer tools, like plugins and modules, which integrate seamlessly into continuous integration, continuous deployment pipelines. E.g., as you build your software, you may update your dependencies along with it. Packages that it supports include CI/CD toolchains, build tools, various platforms, and software/programming languages.
It is one of the best product out there to help developers find and fix vulnerabilities quickly. When we talk about the third-party software vulnerability piece and potentially security issues, it takes the load off the user or developer. They even provide automitigation strategies and an auto-fix feature, which seem to have been adopted pretty well.
Their focus is really towards developer-friendly integrations, like plug and play. They understand the ecosystem. They listen to developers. It has been a good experience so far with them.
Because Snyk has so many integrations and so many things it can do, it's hard to really understand all of them and to get that information to each team that needs it. Since I was the one who originally set up Snyk, I have been in charge of evangelizing all the features of it, but that's almost a full-time job, and that's not my entire job. I haven't been able to get all of that information out quite as well as it could be. If there were more self-service, perhaps tutorials or overviews for new teams or developers, so that they could click through and see things themselves, that would help.
There is so much in there already that it's easy to get a little bit lost, but thankfully they also have great documentation on pretty much all of the features and plugins, to understand them. So it can be up to the person, depending on how much of a self-starter they are, to see an integration and then go poke around and figure out how to get things working.
reviewer1412625 says in a Snyk review
Application Security Engineer at a tech services company with 501-1,000 employees
We tried to integrate it into our software development environment but it went really badly. It took a lot of time and prevented the developers from using the IDE. Eventually, we didn't use it in the development area.
If the plugin for our IDE worked for us, it might help developers find and fix vulnerabilities quickly. But because it's hard to get the developers to use the tool itself, the cloud tool, it's more that we in the security team find the issues and give them to them.
I would like to see better integrations to help the developers get along better with the tool. And the plugin for the IDE is not so good. This is something we would like to have, but currently we can't use it.
Also, the API could be better by enabling us to get more useful information through it, or do more actions from the API.
Another disadvantage is that a scan during CI is pretty slow. It almost doubles our build time.
The documentation sometimes is not relevant. It does not cover the latest updates, scanning, and configurations. The documentation for some things is wrong and does not cover some configuration scannings for the multiple project settings. For example, sometimes the code base condition is consistent on multiple modules. It's kept on different frameworks and packet managers. This requires Snyk to configure it with a custom configuration from the scan. From this point of view, the documentation is unclear. We will sometimes open enterprise tickets for them to update it and provide us specific things for the deployment and scanning.
There is no feature that scans, duplicates it findings, and puts everything into one thing.
The communication could sometimes be better. During the PoC and onboarding processes, we received different suggestions versus what is documented on the official site. For example, we are using Bitbucket as a GitHub system for our code, especially for Snyk configurations. The official web page provides the way to do this plugin configuration. However, if we talk about doing direct connection with our managers from Snyk, they suggested another way.
For a developer, the ease of use is probably an eight out of 10. It is pretty easy to use. There is some documentation to familiarize themselves with the solution, because there are definitely steps that they have to take and understand. However, they are not hard and documented pretty well.
We have integrated Snyk into our SDE. We have a CI/CD pipeline that builds software, so it's part of that process that we will automatically run. We use Jenkins as our pipeline build tool, and that's what we have integrated. It is pretty straightforward. Snyk has a plugin that works out-of-the-box with Jenkins which makes it very easy to install.
Snyk's vulnerability database is excellent, in terms of comprehensiveness and accuracy. I would rate it a nine or 10 (out of 10). They have a proprietary database that is very useful. They are also very open to adding additional packages that we use, which might be not widely used across their customer base.
We are using Snyk along with SonarQube, and we are currently more reliant on SonarQube.
With Snyk, we've been doing security and vulnerability assessments. Even though SonarQube does the same when we install the OWASP plugin, we are looking for a dedicated and kind of expert tool in this area that can handle all the security for the code, not one or two things.
We have the latest version, and we always upgrade it. Our code is deployed on the cloud, but we have attached it directly with the Azure DevOps pipeline.
Contrast Security Assess: Plugin
reviewer1361742 says in a Contrast Security Assess review
Director of Innovation at a tech services company with 1-10 employees
The effectiveness of the solution’s automation via its instrumentation methodology is good, although it still has a lot of room for growth. The documentation, for example, is not quite up to snuff. There are still a lot of plugins and integrations that are coming out from Contrast to help it along the way. It's really geared more for smaller companies, whereas I'm contracting for a very large organization. Any application's ability to be turnkey is probably the one thing that will set it apart, and Contrast isn't quite to the point where it's turnkey.
Also, Contrast's ability to support upgrades on the actual agents that get deployed is limited. Our environment is pretty much entirely Java. There are no updates associated with that. You have to actually download a new version of the .jar file and push that out to the servers where your app is hosted. That can be quite cumbersome from a change-management perspective.
If you are thinking about Contrast, you should evaluate it for your specific needs. Companies are different. The way they work is different. I know a bunch of companies that still have the Waterfall model. So evaluate and see how it fits in your mode. It's very easy to go and buy a tool, but if it does not fit very well in your processes and in your software development lifecycle, it will be wasted money. My strongest advice is: See how well it fits in your model and in your environment. For example, are developers using more of pre-production? Are they using a Dev sandbox? How is QA working and where do they work? It should work in your process and it should work in your business model.
"Change" is the lesson I have taken away by using Contrast. The security world evolves and hackers get smarter, more sophisticated, and more technology-driven. Back in the day when security was very new, people would say a four-letter or six-letter password was more than enough. But now, there is distributed computing, where they can have a bunch of computers trying to compute permutations and combinations of your passwords. As things change, Contrast has adapted well to all the changes. Even five years ago, people would sit in a war room and deploy on weekends. Now, with the DevOps and Dev-SecOps models, Contrast is set up well for all the changes. And Contrast is pretty good in providing solutions.
Contrast is not like other, traditional tools where, as you write the code they immediately tell you there is a security issue. But when you have the plugin and something is deployed and somebody is using the application, that's when it's going to tell you there's an issue. I don't think it has an on-desktop tool where, when the developer writes this code, it's going to tell him about an issue at that time, like a Veracode Greenlight. It is more of an IAST.
We don't have specific people for maintenance. We have more of a Dev-SecOps model. Our AppSec team has four people, so we distribute the tasks and share it with the developers. We set up a team's integration with them, or a notification with them. That way, as soon as Contrast finds something, they get notified. We try to integrate teams and integrate notifications. Our concern is more about when a vulnerability is found and how long it takes for the developer to fix it. We have worked all that out with Power BI so it actually shows us, when a vulnerability is found, how long it takes to remediate it. It's more like autopilot. It's not like a maintenance type of thing.
I would rate Contrast at nine out of 10. I would never give anything a 10, but Contrast is right up there.
reviewer1605099 says in a Contrast Security Assess review
Director of Threat and Vulnerability Management at a consultancy with 10,001+ employees
It's a tiered licensing model. The more you buy, as you cross certain quantity thresholds, the pricing changes. If you have a smaller environment, your licensing costs are going to be different than a larger environment. While the licensing is tiered, there are no or mandatory minimums. With some of our other products, you have to buy at least 50 licenses in a block, or you have to buy 100 in a block. With Contrast, you can buy a single license.
The licensing is primarily per application. An application can be as many agents as you need. If you've got 10 development servers and 20 production servers and 50 QA servers, all of those agents can be reporting as a single application that utilizes one license. That's really outstanding if you want to cover a large environment, because you get a holistic view of an application under a single license.
Licensing is done annually, for us at least, although they might have some flexibility on that. The licensing that I'm talking about is specifically Assess. There's also developer licensing where the developers can have a plugin for their development platforms. That's separate, but the structure is the same. It's also tiered. Depending on how many developers you have, you'll ultimately pay less based on quantity.
I don't believe there are any costs in addition to the standard licensing. However, they do have a part of their licensing model where they assume a certain number of developers are going to be present when you have an application. I don't know if this has changed recently, but if you buy licensing for a number of applications, they're going to assume that there are also a set ratio of developers per application, and therefore you must also buy the developer licensing. One of the challenges we've had with them is explaining to them that that's not how our developers work. In our environment, we have developers who are responsible for multiple applications. If we're buying licensing for our applications, we're somewhat forced into buying developer licensing that we don't need or can't use.
GitGuardian Internal Monitoring: Plugin
Don Magee says in a GitGuardian Internal Monitoring review
Security Engineer at a tech services company with 11-50 employees
It could be easier. They have a CLI tool that engineers can run on their laptops, but getting engineers to install the tool is a manual process. I would like to see them have it integrated into one of those developer tools, e.g., VS Code or JetBrains, so developers don't have to think about it. However, it is moving in the right direction.
I would like to see them take their CLI tooling and make first-level plugins for major development platforms so I don't have to write a script to help engineers set up the CLI tool for their own workstations. That could use some improvement.
When we add new repositories, they don't immediately get a historical scan. Every now and then, when I log into the interface, it is like, "You have five repositories that haven't had a historical scan," and I have to go enable it. That seems weird. It should be automatic.
It is email, so it is out-of-band, which is what we need. It would be cooler if it could be done through Slack or some other means for more urgency. However, it meets our needs. Most of the time, our security team is US-based. A lot of our engineers are in European countries and even places like Australia, so there is a lot of asynchronous work.