In the famous book “Code Complete,” published by Microsoft Press, author Steve McConnel emphasized the importance of writing code for people first and computers second for better code readability. This was in 1993, when cyber attacks were practically non-existent. Fast forward to 2023, we have a greater challenge: writing code for tackling hackers first and users second.  This challenge is compounded by the rise of cybersecurity incidents due to security vulnerabilities in code.

Software Composition Analysis (SCA) tools have been around since 2002, and they are now more critical than ever for identifying vulnerabilities in your codebase's libraries, frameworks, and third-party components. According to a Capterra report, 61% of businesses have been affected by a supply chain threat in the last year. If you’re one of the lucky 39%, Capterra suggests it really came down to luck - as nearly all companies use at least one third-party vendor.

By now, you have probably heard about the recently discovered backdoor into versions 5.6.0 and 5.6.1 of the tarballs of the xz utilities, a popular compression/decompression library for xz files, which provides unauthorized remote access under certain conditions. This vulnerability was reported under CVE-2024-3094. Andres Freund, of Microsoft, who discovered the vulnerability, summarized it well.

We recently wrote about npm audit fix, which is an add-on to the excellent npm audit, that has become a fundamental tool for managing software packages in Node.js projects. However, developers working with other languages also require specialized tools for Software Composition Analysis (SCA). At Jit, our tool of choice for SCA scanning across a diversity of programming languages is OSV Scanner, a best of breed OSS solution maintained by Google.

If over 40 major banks can be the target of JavaScript injection attacks, let’s be honest – so can you. In 2023, a malware campaign using this attack method affected 50,000 user sessions across more than 40 financial institutions worldwide, leaving many dev teams in pure damage-control mode. A large number of professional developers (especially front-end developers) use JavaScript more often than any other programming language.

Zero-day vulnerabilities are the surprise no developer wants to get. Because these security flaws are unknown to developers, they have zero days to prepare or mitigate the vulnerability before an exploit can occur. 62% of vulnerabilities were first exploited as zero-day vulnerabilities, so they are far more prevalent than we think. Even Google Chrome can attest to that after discovering a series of zero-day vulnerabilities that left its billions of users at risk in 2023.

A product is only as secure as its weakest link. That is why many talented security engineers and researchers recommend embedding security as early in the software development life cycle (SDLC) as possible, even from the very first line of code. Or better yet, even before the very first line of code, during the threat modeling and architecture phase. Smart people have been saying this for a very long time. So, why does product security still remain difficult?