Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Noname Security today made generally available an update to a tool for testing application programming interface (API) security that promises to make it easier for DevOps teams to ensure APIs are secure.
Filip Verloy, a field CTO for Noname Security, said Active Testing V2 is purposely designed to make it simpler to integrate API testing within a larger DevSecOps workflow.
Version 2 of Active Testing, for example, provides additional integrations with continuous integration/continuous deployment (CI/CD) platforms along with automated API discovery tools.
Other capabilities included in the latest release are tools to automate API response inspection, troubleshooting, classification and vulnerability discovery.
Finally, Noname Security has also added support for GraphQL-based APIs alongside REST APIs.
In total, there are now more than 160 API security tests that can be employed on an API testing tool that Noname Security developed to enable it to build Active Testing, said Verloy. In effect, Active Testing is an extension of that core API testing tool, he noted.
The biggest issue DevSecOps teams encounter when testing API security is that most legacy tools are not designed to provide any visibility into the business logic used to construct APIs. As such, there is a need for API security tools that can be easily integrated within DevSecOps workflows to discover issues before APIs are exposed in a production environment, he noted.
While a lot of progress has been made toward securing software supply chains, APIs have generally not received enough attention. Developers typically create APIs, but they don’t typically assume responsibility for managing and securing them. As the number of APIs within organizations continues to proliferate, there is a growing need to centralize API management and security.
Historically, developers have assumed that cybersecurity teams were making sure APIs are secure. Cybersecurity teams, conversely, assumed that the developers that created APIs would be responsible for securing them. DevSecOps best practices make it possible to now extend responsibility for security further left toward developers in a way that enables cybersecurity teams to define the policies and controls that should be used, noted Verloy.
It may a while before every organization masters the all the nuances of DevSecOps, but as pending legislation that requires organizations to better secure software supply chains becomes law it’s only a matter of time before organizations revisit API security—if they have not done so already.
In the meantime, cybercriminals have already discovered that insecure APIs provide a convenient mechanism for exfiltrating data that they can then sell or hold for ransom. The number of rogue and zombie APIs that are unknown or that have been forgotten has become a major cybersecurity issue. Ideally, DevSecOps teams would not only test the security of APIs before they are deployed but would also address a significant amount of technical API security debt that has already accumulated.
One way or another, API security is going to become a significant issue in the weeks and months ahead. The issue now is how to address it before it gets any worse.
