{"id":25328,"date":"2022-09-23T11:44:00","date_gmt":"2022-09-23T11:44:00","guid":{"rendered":"https:\/\/www.esecurityplanet.com\/?p=25328"},"modified":"2022-09-26T16:17:01","modified_gmt":"2022-09-26T16:17:01","slug":"software-supply-chain-security-guidance-for-developers","status":"publish","type":"post","link":"https:\/\/www.esecurityplanet.com\/applications\/software-supply-chain-security-guidance-for-developers\/","title":{"rendered":"Software Supply Chain Security Guidance for Developers"},"content":{"rendered":"\n

Whether it\u2019s package hijacking, dependency confusing, typosquatting, continuous integration and continuous delivery (CI\/CD<\/a>) compromises, or basic web exploitation of outdated dependencies<\/a>, there are many software supply chain attacks<\/a> adversaries can perform to take down their victims, hold them to ransom<\/a>, and exfiltrate critical data.<\/p>\n\n\n\n

It\u2019s often more efficient to attack a weak link in the chain to reach a bigger target, like what happened to Kaseya<\/a> or SolarWinds<\/a> in the last couple of years. Attackers can implant an RCE (remote code execution) or harvest developers\u2019 credentials to escalate privileges and perform malicious actions stealthily.<\/p>\n\n\n\n

Besides, they may only have to compromise a single package to distribute malware to a large range of users and organizations, because the current supply chain is insanely complex and interconnected.<\/p>\n\n\n\n

Of course, developers cannot be held responsible for all vulnerabilities, but they usually have privileged accounts<\/a> and even direct access to sensitive documents and pipes, which makes them increasingly attractive targets.<\/p>\n\n\n\n

To help developers protect against supply chain hacks, the U.S. National Security Agency (NSA), Cybersecurity and Infrastructure Security Agency (CISA), and the Office of the Director of National Intelligence (ODNI) recently released a comprehensive guide<\/a> to help them secure their code and processes.<\/p>\n\n\n\n

See the <\/em>Top Code Debugging and Code Security Tools<\/em><\/a><\/p>\n\n\n\n

Stopping Malicious Code Injections<\/strong><\/h2>\n\n\n\n

According to the guide, threat actors still use public vulnerability disclosures but, rather than waiting for them, \u201cthey proactively inject malicious code into products that are then legitimately distributed downstream through the global supply chain.\u201d<\/p>\n\n\n\n

Dev teams often struggle with updates and time-consuming DevOps (development and operations), so they automate CI\/CD pipelines for automated deployments and tests, but the process is sometimes misconfigured and often lacks security checks.<\/p>\n\n\n\n

Another popular technique can consist of compromising a package that is only used by developers (e.g., devDependencies in Node) to harvest their credentials such as AWS keys.<\/p>\n\n\n\n

The new U.S. guidance identifies common threat scenarios during the software life cycle:<\/p>\n\n\n\n

  1. An adversary intentionally injects malicious code, or a developer unintentionally includes vulnerable code within a product.<\/li>
  2. Vulnerable third-party source code or binaries is incorporated within a product either knowingly or unknowingly.<\/li>
  3. Weaknesses within the build process are exploited to inject malicious software within a component of a product.<\/li>
  4. A product within the delivery mechanism is modified, resulting in injection of malicious software within the original package, update, or upgrade bundle deployed by the customer.<\/li><\/ol>\n\n\n\n

    The document lists concrete measures<\/a> to reduce the risk:<\/p>\n\n\n\n