The source code thefts from dozens of companies announced by GitHub in the past two weeks, and the frenetic code dumps by Lapsus$ before that demonstrate how hackers have weaponized the content of company repositories and left everybody from the SOC to the boardroom realizing their current security thinking needs to change.

Here are five common mistakes that security teams are making as they face an unprecedented threat landscape:

  • Thinking that IP is the most important aspect of the company’s code.

From a hacker’s perspective, IP has become the least important aspect of a company’s codebase. When hackers steal code, they’re looking for the systems the code connects to—from other microservices, databases, and remote APIs. Hackers can trace the interconnections in the app just as developers do when writing and maintaining the code. Next, they’re looking for the secrets to access those systems. The user and password to access that database, the keys to connect to that API, the GRPC/TLS client certificate used by that set of microservices, and the certificate signing request and private key used to generate the SSL certificates that prove the company’s identity on the web. They are also looking for the code-signing key used to prove the authenticity of their apps all fall into this category, along with far too many other bits that only work if they’re kept private.

  • All the company’s code resides in private repos.

The terabytes of code dropped by Lapsus$ were all in private repos—including thousands of passwords, private keys, root signing certificates, API tokens, and other secrets. Developers need broad access to code to stay productive. As companies scale, that can add thousands of developers with access, but very few of those developers need access to the production keys and certificates stored in those repos with the code.

  • Believing that if hackers enter the company’s code, it’s the end of the world.

An attack on code isn’t a rare mass extinction event like a meteorite striking earth. Life carries on and customers, investors, boards, and federal regulators are demonstrating little patience or sympathy for the companies targeted in these attacks. Executives who claimed naivety in the Lapsus$ events have been mocked, and a Texas court ruled recently that a liability suit against the execs at SolarWinds code supply chain attack can proceed. Attacks on code are a regular occurrence: security team have to decide what they can do to mitigate the risk.

  • Thinking other tools will protect the company.

The news about software supply chain attacks following the 2020 SolarWinds attack has driven many companies to implement external supply chain monitoring tools without recognizing the risks in their internal supply chain. External supply chain risks are significant, but the series of Lapsus$ and GitHub events demonstrate external code supply tools aren’t enough to prevent or mitigate code attacks.

  • Spending too much time on a DAST implementation.

I’ve met countless CISOs and AppSec leaders focused on comprehensive SAST or DAST implementations that are consuming so much time and budget they can’t fix the basics like secrets in code. SAST and DAST are useful tools, but it’s time to think of security as a process, not a single product.

Hackers target secrets in code because security leaders are focused elsewhere. With more than 70 million users and 100 million repos on GitHub, hackers will have easy pickings for quite a while. Will your company be one of them?

Casey Bisson, head of product and developer relations, BluBracket