It’s no secret that most application security teams are overextended and short-staffed. In fact, a recent ESG study showed that many cybersecurity professionals experience increased stress and job burnout.

Malware has come a long way since it first made the scene in the late 1990s, with news of viruses infecting random personal computers worldwide. These days, of course, attackers have moved beyond these humble roots. Now they deploy a variety of innovative techniques to extract large amounts of money from businesses around the world. A similar development is taking place with malware’s upstart cousin – the emergence of malicious packages being uploaded to package registries.

The proliferation of third-party software components such as open source software(OSS) has triggered a growing need to keep track of it all. Why? Because when security vulnerabilities inevitably crop up in open source components, it’s pretty important to know whether your company uses that piece of code – or whether it appears in the myriad software dependencies inherent in open source.

As security researchers, we see new malicious methods being introduced on a daily basis from the ever-industrious global cadre of malicious actors. But not all of the things we find constitute breaking news. Sometimes, we run across something that doesn’t necessarily pose a threat, but still piques our interest. Instead of being the security equivalent of a four-course meal, it’s more of an amuse bouche.

A possible method of attacking your code base is a bit of social engineering that involves using open source to report potential bugs in software that provides reproduction applications. These applications can include malicious code that can compromise your software and applications. In the blog post, we’ll briefly look at why and how they operate, and how to mitigate this practice.

Recently, there have been some remote code execution (RCE) attacks that included just a single line of well-built code that can run a remote shell. Let’s take a look at why and how these attacks work, why npm is particularly susceptible, what could happen if they get into machines, and how to detect and fix them.

Static Application Security Testing (SAST) is one of the principal techniques for assessing the source code of applications to detect possible vulnerabilities. SAST enhances application security during the early stages of the development life cycle and plays an important role in shifting security left. However, there are quite a few myths that are often associated with implementing SAST security tools. Let’s run through the big three.

What are cloud-native applications? According to the Cloud Native Computing Foundation (CNCF), the term “cloud native” describes systems that are specifically designed to help build and run scalable applications in all cloud environments, including public, private, and hybrid clouds. Cloud-native applications use the attributes of cloud architecture in ways that legacy systems can’t. They don’t need any onsite computing infrastructure and can scale quickly to meet demand.

Monero (XMR) is an open-source, privacy-oriented cryptocurrency that was launched in 2014. It uses a public distributed ledger containing technology that obscures transaction details to ensure the anonymity of its users. Monero maintains egalitarian mining, allowing anyone to participate. As tempting as it may seem, some go a step further and use the infrastructure of others to participate in mining. Cryptocurrency mining was originally performed using CPUs, and Monero was no different.]

The continuing escalation in cyberattacks on large corporations, coupled with an acceleration of digital transformation, has forced organizations to reassess their security strategies and infrastructure. This escalation has driven growth in the adoption of zero-trust application security and compliance. The zero-trust approach means that no devices or software should be trusted by default, even if they have permissions and previous verification.