What is your primary use case for Fugue?

My main use case for Snyk is to identify security vulnerabilities in application code and dependencies during the development lifecycle, before the code is deployed to production. Once developers develop and push code to the repository, Snyk can scan the code and identify potential vulnerabilities early in the development process. Before implementing Snyk, we did not have a dedicated tool to identify vulnerabilities before deployment. This meant that some security issues could only be identified after the application was already deployed, where tools such as CrowdStrike could help detect security-related issues at the endpoint or runtime level. With Snyk, we can shift security testing earlier in the Software Development Lifecycle (SDLC). Developers can identify and address vulnerabilities while they are developing and testing the application, rather than discovering them after deployment. This is particularly important because we want to minimize the risk of security issues reaching production. Fixing vulnerabilities after deployment can potentially impact production environments and, ultimately, our customers. By integrating Snyk into our development and CI/CD process, we can identify vulnerabilities earlier, give developers an opportunity to remediate them before release, and improve the overall security and stability of our applications. In summary, our primary goal is to shift security left by identifying and remediating vulnerabilities before code reaches production, reducing production risk and protecting our customers.

My main use case for Snyk involves finding and fixing security issues during application upgrades and migrations. In my work at ADP, I primarily use it to scan applications for vulnerabilities, identify risky dependencies, and help the team remediate issues before they become production problems. We had an initiative called Mythos where we had to upgrade the application and fix all security issues, and Snyk was very helpful during that time. In one of the Mythos upgrades, Snyk highlighted a dependency vulnerability that was buried in the package chain, which was not something we would have caught quickly by manual review. Because it surfaced early, we fixed it during the upgrade itself instead of dealing with it later, which immensely reduced the risk and kept the rollout on track. That was one of the incidents that I had with Snyk, and it was absolutely very helpful during this complete Mythos upgrade for all the team members. Another important part of how Snyk fits into my workflow is that it helps shift security left. Instead of waiting until the end of a project to discover vulnerabilities, we can catch them while we are still upgrading, migrating, or making any code changes. It also fits well into the developer workflow because it is just another plugin that we have in Visual Studio Code to be enabled to ensure all security issues are scanned and displayed visually. Once that is done, we can fix it in a matter of time, so having it as an extension in Visual Studio Code is one of the important things for developers because it becomes easily integrated into the workflow they are working with.

We are a customer of Snyk, which is a SaaS solution. We are one of the tenants using Snyk services but are not doing any enhancement development. We are purely a customer availing Snyk services. We are also using a separate DAST tool, though I am not aware of the tool name as it is managed by a different team. We utilize two main capabilities: application vulnerability detection and SCA capabilities. The primary reason we use Snyk is for SAST, as we want to scan our applications for any security vulnerabilities and address them.

I typically use Snyk for checking the security and vulnerabilities in my repositories. Recently, I have used Snyk in one of my repositories for security and vulnerability checks, providing comprehensive knowledge about the repository, including what it does and where the security vulnerabilities are located. I am using Snyk for the first time and did not use any vulnerability scanning solution before this. I was previously doing Red Hat vulnerability scanning locally for dependency checks, which was not what I wanted.

The most recent client had experience with other products that did not have some features Snyk provides, such as Fortify in the old version before OpenText acquisition. They gave feedback about the precision in discovering vulnerabilities. They found that Snyk can provide more insights about vulnerabilities than older applications in SAST and SCA. We have integration with GitHub Actions to analyze the code and we use a double check in the pipeline. Our strategy is about shift left. The developers connect with Snyk, Git, and use this with the pipeline.

I use Snyk ( /products/snyk-reviews ) in the DevOps pipeline to identify vulnerabilities before deploying the application. It integrates with Jenkins ( /products/jenkins-reviews ).

I lead a code security practice for our organization. We integrated Snyk into our GitHub, using CLI to automatically scan codebases and identify issues. We are a large organization with three independent entities, consolidating Snyk across all entities. We also provide access through numerous CI/CD tools. Our default implementation mechanism is CLI, but we also use the Web UI for a comprehensive view and recommendations.

The main tool today is used to check for security issues in our products. We use it to analyze all the projects, and our security efforts are based partly on this tool.

Snyk protects vulnerabilities in the code as usual, detects abnormal data flow inside the field, and similar tasks.

I use the tool in my company to scan open-source projects.

We are using an enterprise version of Snyk for image scanning. We use Snyk to identify and address vulnerabilities in our open-source dependencies and to scan the Docker images.

We use Snyk for the generation of SBOM for Docker. We use it to check the standards of the CSI benchmark that we have implemented in the containers and the applications by Java Spring Boot.

We use the product mainly for software composition analysis. It is used to identify vulnerabilities in the application plug-ins. If we use Python 3.8, it’ll tell us that the version is outdated and that it has several vulnerabilities. It also helps in threat identification. It also provides infrastructure as code.

We use Snyk to check vulnerabilities and rectify potential leaks in GitHub.

The major problem my company found in relation to our customers was in the area of Zip Slip security as they don't have any security tools in place. My company's customers don't have any security tools integrated into the CI/CD pipelines they use in their company. With Snyk, SCA checks code and third-party dependencies upfront.

In my company, Snyk is useful because it provides container security and DAST.

We use some legacy and some new languages as we are aiming for serverless solutions. We're using serverless as is and with Python. We import it to Snyk to do SAST scanning for every one of our repositories on the Bitbucket pipeline. At least 350 repositories, including libraries and some automation such as robots or scripts. We have a huge background in using this tool.

At a high level, Fugue extends and augments compliant reporting capabilities provided by major cloud suppliers. It enhances the visibility, again, from a compliance standpoint, into cloud-based or multi-cloud-based environments.

We use Fugue to gain better visibility. It enhances the ability of Kubernetes operational management within the Azure platform. We use it to extend, monitor, and operationally manage the capabilities of Kubernetes' workloads.