Earlier this month, a group of researchers at the University of Cambridge published an academic paper, with an accompanying website, on a new type of potential vulnerability that could appear in source code. They called it Trojan Source.
Given the large and growing number of cyber attacks that exploit software vulnerabilities, vulnerability management is critical. A variety of unintended consequences can result from misjudging the severity of an existing vulnerability. Legal battles, financial losses, and reputational damage are all possible outcomes for a business. To combat today's modern cyber security challenges, it's critical to have a vulnerability management program in place.
JFrog security research team (formerly Vdoo) has recently disclosed a code injection issue in one of the utilities shipped with Tensorflow, a popular Machine Learning platform that’s widely used in the industry. The issue has been assigned to CVE-2021-41228. This disclosure is hot on the heels of our previous, similar disclosure in Yamale which you can read about in our previous blog post.
As organizations look for solutions that enable them to create a software bill of materials (SBOM) to ensure they’re meeting new governmental mandates for protecting the software supply chain, it’s important to understand the difference between solutions based on reporting vs. remediation. The primary focus of any SBOM solution should be on open source code. The use of open source continues to expand exponentially. Open source components comprise 60%-80% of today’s applications.
Project Memoria is the largest study on the security of TCP/IP stacks. The idea for this project emerged in May 2020 while collaborating with JSOF on Ripple20. Our researchers understood that the problem with TCP/IP stacks was much deeper and more widespread than initial research had suggested. We hypothesized that similar issues to those identified in Ripple20 could be present in other stacks as well.
Managing application resources at scale can be tricky business. As such, many DevOps and AppSec teams turn to using a declarative framework rather than writing individual scripts to deploy, manage, and maintain access controls for their resources. For Azure environments, Azure Resource Manager (ARM) is this management layer that allows teams to manage their infrastructure as code (IaC) through declarative ARM templates.
On its surface, CVE-2021-42292 doesn’t look like the kind of vulnerability that a network-based tool can find reliably. Marked by Microsoft as a local file format vulnerability, security veterans would expect that between encryption and encoding, there would be a million different ways to evade network detection with a weaponized exploit.
The Open Web Application Security Project (aka OWASP) recently announced its latest updates to the venerable OWASP Top Ten list. This publication is meant to bring attention to the most common classes of software-related security issues facing developers and organizations in the hopes of helping them to better plan for and address potential high-severity issues in their codebases.
If every vulnerability seems to be equally critical, engineers would get overwhelmed and probably waste time on the wrong issues. This is why it’s important for developer security tools to provide clear and simple prioritization functionality. As you’ve likely noticed, Snyk Code provides a Priority Score on the top right corner of the overview panel. When hovering over it, an explanation is shown how the priority score was calculated.
