Application Security Azure Reviews
Showing reviews of the top ranking products in Application Security, containing the term Azure
Microsoft AzureView full review »
reviewer1451970 says in a Veracode review
R&D Director at a computer software company with 201-500 employees
We tried to create an automatic scanning process for Veracode and integrate it into our billing process, but it was easier to adopt it to repositories based on GIT. Until now, our source control repository was Azure DevOps Server (Microsoft TFS) to managing our resources. This was not something that they supported. It took us some sessions together before we successfully implemented it.
Micro Focus Fortify on Demand: Azure
Microsoft AzureView full review »
Whenever we have a new application we scan it using Micro Focus Fortify on Demand. We then receive a service connection from Azure DevOps to Micro Focus Fortify on Demand and the information from the application tested.
We are using Micro Focus Fortify on Demand in two ways in most of our processes. We are either using it from our DevOps pipeline using Azure DevOps or the teams which are not yet onboarded in Azure DevOps, are running it manually by putting in the code then sending it to the security team where they will scan it.
We use two solutions for our application testing. We use SonarQube for next-level unit testing and code quality and Micro Focus Fortify on Demand mostly for vulnerabilities and security concerns.
Since we are using the community version, we have had some issues. For example, we have had some difficulties with the Single Sign-On (SSO) login. We tried to integrate with our Azure ID to have access to login, but it doesn't always update. We have to search for more forums, or in other communities for technical IT.
The documentation is not clear and it needs to be updated. As it is the community version we don't have team support and rely on the documentation that is available. We are creating more disciplines to do peer reviews on SonarQube. There is time spent on creating the tools but not the documentation that is needed for support.
It takes time to configure and create profiles. We need to improvise the way we introduce new tools.
We have only integrated the source code, but there are things that are not being utilized because it is product-driven and there needs to be more path and delivery.
Since we are now certified, we are utilizing more and we are creating an environment for security. We need more emphasis on the security side.
Support needs to improve with their response time.
There is a lack of local partners/vendors in our region and we are having difficulties finding vendors looking for another partner.
In the next release, I would like to see some automation scripts. At times by default, you have to configure some of the rules in the detection. You need some parameters to be set that define the source code, such as those required to eliminate a false positive.
They advance their product without addressing security or internal codes.
We deploy SonarQube on-premise on a Linux server and our pipelines were created with GitLab and Azure DevOps. Meaning that Azure DevOps and GitLab are the tools that do the build and release process.
We use Microsoft Azure and Google Cloud Platform a little.
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: Azure
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 Firewall: Azure
reviewer1534461 says in a Sonatype Nexus Firewall review
Senior Cyber Security Architect and Engineer at a computer software company with 10,001+ employees
For people who don't have a lot of Linux knowledge—including myself, I'm purely a Windows guy—it can be very tricky. It did take us a long time to stand up the environment.
The fact they don't have professional services to implement it for you is a big gap. I have a good relationship with everyone on the Sonatype team. I sent them an email and they made time to jump on a call and help us build it. That is what is expected from a large, enterprise-level company. We have Azure Sentinel and F5 and these companies have professional services. They help you from end-to-end, starting with the implementation. Sonatype does not have been at the moment. It does become challenging when you're not a Linux guy and you need to learn and implement it and to make sure that you're deploying it securely.
To be fully ready, it took us two months. I was involved, along with one of my engineers, and we had the help from Sonatype team.
In terms of an implementation strategy, we had the whole high-level architecture set up, which was not very hard. But to engineer it and do it was a little challenging for me, but it could be different for people who have Linux knowledge.
There are about 200 people using it across our organization. Most of them are developers and data scientists. I take care of the day-to-day maintenance. The upgrades are easy, the directions are easy. If you do need help, you can reach out to the support.
Sonatype Nexus Lifecycle: Azure
We use Azure DevOps as our application lifecycle management tool. It doesn't integrate with that as well as it does with other tools at the moment, but I think there's work being done to address that. In terms of IDEs, it integrates well. We would like to integrate it into our Azure cloud deployment but the integration with Azure Active Directory isn't quite as slick as we would like it to be. We have to do some workarounds for that at the moment.
Also, the ability of the solution to recognize more of the .NET components would be helpful for us.
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.
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.
CAST Highlight: Azure
CAST Highlight is easy to use and has a good dashboard.
This solution integrates well with Azure DevOps and you can import the dashboard into that environment.