Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

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. 67.9% of professional developers use JavaScript more often than any other programming language. Its popularity is understandable, given its versatile and interactive capabilities.

In the evolving landscape of software development, where dependencies and third-party packages are increasingly baked into the fabric of our applications, understanding and managing the risk associated with these components has become paramount.

As a company building a SaaS security product, our inherent culture is not only focused on building best of breed security products for our users, but also ensuring that our systems, practices and workflows are engineered to support a continuously evolving threat landscape, and to protect our users’ data. We’ve written about our design for tenant isolation for our serverless based architecture in the past, and practical methods to avoid data leakage between clients.

With the growing number of security frameworks, acronyms, scoring systems, benchmarks and more, it’s often hard to understand how each frameworks differs, how and where they come into play with regards to modern cloud native systems. More than anything, how do we actually operationalize these frameworks to derive engineering benefits?

When a new vulnerability is found, the race is on to either solve it or exploit it (depending on which side you’re on). But while attackers are getting faster, companies not so much. Dev teams take around 215 days to resolve a security vulnerability. The numbers are only marginally shorter when dealing with critical vulnerabilities. This delay is particularly concerning given the rise in zero-day exploits, where hackers take advantage of a security flaw before the organization even knows it exists.

DevSecOps pipelines arose in response to DevOps and CI/CD, which made it possible for developers to iteratively and continuously deliver small code changes, rather than massive deployments periodically. In theory, by integrating security into DevOps processes that enable continuous integration and delivery, developers could find and resolve security issues early in the software development lifecycle (SDLC), which is much faster than fixing security issues in production.