The state of APIs, DevSecOps guidance from NSA & CISA, and more

Every Wednesday, Nick Chase and Eric Gregory from Mirantis go over the week’s cloud native and industry news on the Radio Cloud Native podcast.

This week, John Jainschigg stepped in for Nick, and John and Eric discussed:

• Recent "State of APIs" reports focusing on both security and the wider development landscape

• New DevSecOps guidance from the NSA & CISA

• The new auto-refreshing CVE feed for Kubernetes

• PyTorch's big move from Meta to the Linux Foundation

• And more on the podcast, including hierarchical namespaces in Kubernetes and the Linux veterans driving Rocky Linux's corporate sponsor CIQ

You can watch the entire episode below or download the podcast from Apple Podcasts, Spotify, or wherever you get your podcasts. If you'd like to tune into the next show live, follow Mirantis on LinkedIn to receive our announcement of the next broadcast.

John: An article over on Container Journal, posted about a week ago by Bill Doerrfeld, pointed out that Salt Labs’ State of the API Security Report, released for Q3 2022, enumerated a 117% YoY increase in API attacks. He quotes John Morello, VP of Product at Palo Alto Networks, in noting that APIs are prone to data overexposure, and that traffic to and from them (obviously) tends to be complex, involving both relatively arcane requests and often tending to retrieve more data than absolutely needed for a transaction – in part because it’s often easier, I guess, to request a bag of JSON and sift through it on the client side.

This, in turn, means that policing API security requires more intelligence to understand transactions. But basics are also important. Principle of least privilege/Zero trust is the foundation – Just-in-Time privilege escalation is a way to manage it.

Morello also says Web Application Firewalls aren’t always the right or whole solution for defending APIs, since they’re too generalized – once you get into configurable APIs, traffic in and out can take use-case-specific forms that generalized tools will need adaptation or supplementation to recognize and make decisions about.

He also makes the point that REST isn’t the only API style going – think graphQL, gRPC and other types. And security solutions need to know about all of these to create effective barriers to exploitation.

Meanwhile: Postman, everybody’s favorite REST API exploration and munging toolkit, has released their State of the API report for 2022. As you might expect, investments in API development and integration are going up again, as is the amount of time programmers spend working with APIs – the past three years have seen consistent increases here, and respondents to the survey indicated that their orgs are now spending more than half their productive time in API-centric work. There’s also evidence that orgs are finally creating real momentum behind use of APIs internally – how well an API integrates with internal apps and systems is now the number one reason decision makers are choosing to use one contender (or service) over another.

What APIs are in use? Postman is probably getting a pretty good view of this because they’re so widely used. SalesForce APIs top the list, and quite a few productivity-suite apps, like Microsoft Graph, Notion and Zoho, are right up there, as are the predictable payment APIs, DocuSign, and several key communications apps, including Twitter in the number two spot, Slack (of course), and WhatsApp. More intense, less-mashup-y dev-centric APIs like MongoDB are relegated to the bottom of Postman’s general list, and it would be interesting to see broken out into a list of databases and components frequently encountered in cloud native environments.

For me, a big take-away of the Postman report is how many new people are now coming into API-centric development, and how scary it potentially is that almost half the people working with APIs today have less than two years experience. Definitely points up the need for good security standards and tools, secure-from-the-start engineering protocols, and other best practices to avoid problems. Another still-partly-hidden cost of naive approaches to using and designing APIs, suggests Postman, may be a growing overdependence on microservices (i.e., components that just do one thing, so have very simple APIs) as a design pattern – something that can bring with it, its own problems.

Eric: Earlier this month, the National Security Agency (NSA), Cybersecurity and Infrastructure Security Agency (CISA), and the Office of the Director of National Intelligence (ODNI) jointly released new guidance aimed at developers and intended to help harden software supply chains. The document, titled “Securing the Software Supply Chain: Recommended Practices Guide for Developers,” is exactly what it says on the tin: a list of DevSecOps best practices developed under the Enduring Security Framework (or ESF), a public-private working group coordinated by the NSA and CISA.

The group is releasing the document as entities across the public and private sectors remain focused on risks in the software supply chain, especially in the wake of the SolarWinds attack and vulnerabilities like this winter’s Log4Shell, both of which are explicitly cited by the document. As many teams or at least security experts try to shift security left toward the developer side, this kind of resource is designed as a bit of educational support, providing some basic supply chain security grounding.

The guidance is broken down into four major categories, all phrased as imperatives:

• Develop secure code

• Verify third-party components

• Harden the build environment

• Deliver code

Under these general umbrellas, the document covers everything from expected refrains like vulnerability scanning and SBOMs to less common topics like the security dimension of code reviews. 

The guidance is about sixty pages, but roughly a third of that is appendices, so it’s not a massive read. If you’re looking for up-to-date developer-focused security guidance, you can check it out here.

Eric: On Monday, the Kubernetes SIG Security team announced the alpha release of an official, programmatic CVE feed, which auto-refreshes with reports of critical vulnerabilities. You can access the feed through a web interface or JSON feed. 

The SIG Security team is actively soliciting feedback in order to graduate the release, so if you have thoughts or you’d like to help out, head to issue 1 at the kubernetes/sig-security GitHub page.

Eric: The Linux Foundation announced this week that it’s accepting PyTorch from Meta née Facebook. PyTorch is the pivotal platform for AI, machine learning, and deep learning that has developed a rich ecosystem over the course of its incubation at Meta under the AI team there. As Jim Zemlin writes in the announcement blog for the Linux Foundation:

“If you peel back the cover of any AI application, there is a strong chance PyTorch is involved in some way. From improving the accuracy of disease diagnosis and heart attacks, to machine learning frameworks for self-driving cars, to image quality assessment tools for astronomers, PyTorch is there.”

According to the blog, PyTorch is among the five fastest growing open source projects by commits last month, alongside Kubernetes and the Linux kernel. The Linux Foundation argues that with neutral ownership, PyTorch will be well-positioned to double down as a ubiquitous industry standard, with users being able to trust that it will continue to be maintained as part of the commons.

This feels pretty big. Certainly the Foundation’s messaging around the story is practically vibrating with excitement. How significant is this move, do you think?

Check out the podcast for more of this week's stories.