When it comes to application security – the vulnerabilities that make trouble in the code that ships at the end of the software development lifecycle – the two critical areas that have had their time in the sun in the last year are API vulnerabilities and supply chain failures. 

API vulnerabilities

The more enterprises seek to transform their customer-facing operations, the more they need to expose their data and back-end processes to web and phone apps via public APIs. The more capability that is exposed via those APIs, the greater the risk an attacker can get beyond the controls that govern the API’s behaviour.

While it’s rare for a hacking victim to identify the vector an attacker used, API attacks have been implicated in many high-profile data breaches in the last 12 months – namely Optus and Medibank in Australia, and T-Mobile and Twitter in the USA.

Before an enterprise begins implementing measures to secure APIs, they need to know what’s out there, according to Manjunath Bhat, VP analyst in Gartner’s DevOps and software engineering team.

“CIOs and CISOs must catalogue and classify APIs, both internal and external, to inform a proper risk assessment and enable engagement with API owners and delivery teams," said Bhat.

That risk assessment should cover data sensitivity, business criticality, and customer impact.

According to Bhat, API security should be integrated into the software development lifecycle, with security and software engineering teams working together “…to enable self-service API specification validation, API security testing and catalogue registration (to register their use of APIs).”

Software supply chain security 

After years of high-profile software supply chain attacks, the world is seeing a concerted effort being applied to solving the problem.

In 2021, the USA’s Cyber and Infrastructure Security Agency (CISA) and National Institute of Standards and Technology (NIST) identified the most common supply chain attack types as hijacking updates; undermining code signing; and compromising open-source code.

CISA noted, “Many third-party software products require privileged access”, and “many third-party software products require frequent communication between a vendor’s network and the vendor’s software product located on customer networks”. 

Gartner’s Bhat said two key toolsets that help secure the supply chain are the software bill of materials (SBOM); and complementary vulnerability exploitability exchange (VEX) metadata for the software they are procuring. 

“Multiple factors are driving the need for SBOMs – increased use of third-party dependencies and open-source software, increased incidence of software supply chain attacks and regulatory compliance mandates … all point to the need for visibility and transparency into the components used to build software,” Bhat said.

“Enterprises should also look at runtime/dynamic SBOMs because they provide visibility to component usage when the system is running, including dynamically loaded components and external API calls.

“Fuzz testing and software composition analysis are recommended practices to mitigate supply chain risks.”

The CISO's view

Infosec veteran, Pickles Auctions’ CISO Peter Sandilands suggested that the basis of mitigating software supply chain risks is the software inventory.

Enterprises bound by the Australian Prudential Regulatory Authority that are covered by Prudential Standard CPS 234 Information Security can require their suppliers to complete a security assessment of their software, or the enterprise can assess software before it's deployed. 

Once software has passed testing, enterprises need to apply discipline.“Anything that’s put in your repository is assessed properly for security before it goes in, and after that, you make sure it’s the only version you use,” he said.

Sandilands feels API security is perhaps more difficult, because the industry’s handling of API risks is less mature.

“The ability to do rapid change – where DevOps came from – is valuable and helps build platforms quickly and have them respond to customer demand, but it can sidestep the discipline about what was deployed, where it’s deployed, and so on,” he said.

According to Sandilands, an API catalogue helps – if the enterprise is positive the catalogue is comprehensive.

Ultimately, he said, API security is a people problem: the CISO has to be able to convince development teams to adopt the disciplines that protect customer data and enterprise systems during the development cycle.

And in looking at tools, Sandilands said, don't forget to check the applications and APIs against the Open Web Application Security Project (OWASP) Top 10, and the Australian Signals Directorate's Information Security Manual's recommendations.