Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Snyk

Snyk & ServiceNow

Did you know that up to 90 percent of modern software uses open source software? Often SecOps, AppSec and IT teams don’t have a complete view of their application security risk across the organization. The Snyk and ServiceNow integration efficiently finds, prioritizes, and tracks vulnerabilities in open source dependencies to get a complete view of your application security posture and drive smarter, faster fixes in ServiceNow workflows.

Snyk & Atlassian: How to embed security in AI-assisted software development

Adding AI to your software development life cycle (SDLC) comes with great opportunities — and great dangers. Is the risk worth the reward? This was the topic of conversation when Sascha Wiswedel, Senior Solutions Engineer at Atlassian, and Simon Maple, Principal Developer Advocate at Snyk, teamed up to discuss security in the (AI-assisted) software development lifecycle.

Reporting AppSec risk up to your CISO

For security leaders, building a strong working relationship with your CISO often comes down to your ability to provide clear reports and concise risk summaries. Your reports allow CISOs to perform a vital responsibility of their role: translating highly technical security jargon into actionable recommendations that will reduce risk and improve security maturity across the organization. And in the case of a breach or zero-day event, CISOs may be the bearer of bad news.

Automatic source locations with Rego

At Snyk, we are big fans of Open Policy Agent’s Rego. Snyk IaC is built around a large set of rules written in Rego, and customers can add their own custom rules as well. We recently released a series of improvements to Snyk IaC, and in this blog post, we’re taking a technical dive into a particularly interesting feature — automatic source code locations for rule violations.

Leaky Vessels deep dive: Escaping from Docker one syscall at a time

The Snyk Security Labs team recently embarked on a research project into the Docker engine. During this project, I had the opportunity to perform what is arguably my favorite kind of research using my favorite selection of tools. The research panned out quite successfully, and we identified four high severity vulnerabilities that allow a malicious attacker to break out of a container environment with a controlled Dockerfile under docker build and, in one case, docker run.

10 GitHub Security Best Practices

The security landscape is constantly changing. As such, this blog has been updated to reflect the risks developers and security teams face today and how to overcome them. In our rapidly advancing, code-dominated digital landscape, safeguarding your codebase takes center stage. GitHub is the go-to platform for code sharing and version control in the developer community. However, given its widespread adoption, GitHub is not immune to many of the security challenges that developers face daily.

Why the future of AppSec is ASPM from Snyk AppRisk

Applications are getting bigger and more complex. With sprawling software supply chains, distributed developers, AI-enhanced productivity, and more technology, deployment, and cloud options than ever securing applications is harder than ever. To enable fast and secure development in this new reality, AppSec needs a comprehensive, proactive approach — one that helps address what matters most to reduce risk. They need to implement ASPM to shift the AppSec paradigm.

Buildkit GRPC SecurityMode privilege check: Build-time container breakout (CVE-2024-23653)

Snyk has discovered a vulnerability in all versions of Docker Buildkit <= v0.12.4, as used by the Docker engine. The exploitation of this issue can result in container escape to the underlying host OS when building an image using a malicious Dockerfile or upstream image (i.e, when using FROM). This issue has been assigned CVE-2024-23653.

Buildkit build-time container teardown arbitrary delete (CVE-2024-23652)

Snyk has discovered a vulnerability in all versions of Docker Buildkit <=v0.12.4, as used by the Docker engine. Exploitation of this issue can result in arbitrary file and directory deletion in the underlying host OS when building an image using a malicious Dockerfile or upstream image (i.e, when using FROM). This issue has been assigned CVE-2024-23652.