Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

You probably know the story of “the boy who cried ‘Wolf!’” In the ancient fable, villagers tire of a shepherd’s false alarms, and stop paying attention to them. That’s a lesson for software security teams, not just schoolchildren. Raising concerns about threats that turn out to be flimsy or false erodes the trust that binds your department, and even the faith your customers have in you.

The U.S. Department of Homeland Security (DHS) Cybersecurity and Infrastructure Agency (CISA) has been quite busy this year. It recently issued a “Shields Up” advisory, highlighting that “Russia’s invasion of Ukraine could impact organizations both within and beyond the region,” including the threat of malicious activity against U.S. interests and companies.

By now, you’re probably all aware of the recent Log4j and Spring Framework vulnerabilities. As a recap, the Log4j vulnerability – made public on December 10, 2021 – was the result of an exploitable logging feature that, if successfully exploited, could allow attackers to perform an RCE (Remote Code Execution) and compromise the affected server.

Snyk Code separates itself from the majority of static code analysis tools by generating and maintaining rule sets for its users — helping them combat common and newly discovered threats. A recent Hub article described a new Javascript vulnerability called prototype pollution, which allows attackers to modify, or “pollute”, a Javascript object prototype and execute a variety of malicious actions.

The migration of assets to the Cloud has been the common denominator in company business strategies over the last two years, coupled with the rising number of incidents involving the theft of sensitive information and user passwords on Cloud platforms. According to the Verizon Data Breach Report 2021, in 2020 29,207 real-time security incidents were detected, out of which 5,258 were confirmed data breaches.

Is your team drowning in container vulnerability noise? Are you spending a lot of time figuring out where to focus resources on and still missing dangerous vulnerabilities? Know that you are not alone. Container environments revolutionized app development by enabling unprecedented velocity, but not without a price. The use of readily available container images of third-party and open-source code enabled much faster cycles, but also facilitated the introduction of vulnerabilities in the application.

Vulnerabilities are everywhere. Vetting, mitigating, and remediating them at scale is exhausting for security practitioners. Let’s keep in mind that no organization has the capacity to find and fix all vulnerabilities. The key is to understand what a vulnerability is, interpret the meanings of the CVSS score, and prioritize and effectively use resources within constrained time limits or delivery windows. Since 2016, new vulnerabilities reported each year have nearly tripled.

A few days ago it was reported that the new Go versions 1.18.1 and 1.17.9 contain fixes for a stack overflow vulnerability in the encoding/pem builtin package, in the Decode function. Given the high popularity of Go among our customers and in the industry at large, this update led us to investigate the vulnerability in previous versions.

As Synk announces its support of unmanaged dependencies (mostly C/C++ libraries), we thought it would be beneficial to introduce our non-C community to some common, high-risk dangers that lurk in the C world (get it?). Think of this as a “beginners guide” to C and C++ vulnerabilities, how they look, what problems they may cause, and how to fix them.