API Governance: A Must for Well-Regulated Industries
Governance remains an overused, loosely applied word. In practice, governance, risk and compliance (GRC) teams are stuck in command and control and are isolated from operations. They are still too focused on raising awareness instead of on automating best practices.
API governance has emerged as an opportunity to integrate best practices, GRC, security and quality into your entire API lifecycle. API governance is about platform-driven collaboration, not people-driven compliance, which in turn frees up your engineers to be the creative knowledge workers they are meant to be.
What Is API Governance?
API governance, unsurprisingly, begins with API discovery. As your organization grows, so does your sprawl of APIs and the tools that are serving them. You can’t govern what you don’t know exists, right? You have to understand where your APIs are — both internal and third-party integrations — and who owns what access to what data.
As technical writer Janet Wagner describes it, the main goal of API governance must be consistency across hundreds and even thousands of APIs. Consistency also gets into the quality and compliance — so your internal and external users know what to expect.
Consistency is best achieved through centralization, which helps monitor the access and flow of data. This centralization also allows for templates and reusability, saving thousands in the time and money — on average about $20,000 — it takes to build an API from scratch.
Governance as a term sounds like old-fashioned, top-down data and security management. That Big G security and governance notoriously slows down innovation and release cycles. As Raymond Peng, digital engagement lead at Google, pointed out, without platform-driven, automated governance comes with reworking speed bumps at the architecture review, API design review, internal standards review and, finally, the deployment review, which significantly slows down any partnership or API monetization strategy. He says the knee-jerk reaction to these avoidable hurdles is to try to lump dozens of API releases together, which has you going from agile back to waterfall.
API Governance over Tooling, Not People
Governance is a free-flying term unless you actually enforce it. Just like a zero-trust culture, governance needs to be implemented via tooling, not people. Everything has to center on collaborative governance delivered by a platform. It is about enforcing certain quality and security standards, while also monitoring an API and what data it’s sharing and what services it’s connecting to. Ideally, this is done throughout the full API lifecycle, from design all the way to deprecation — instead of governance being the last hurdle crammed in before deployment.
API governance is typically achieved by treating the API like a contract. An API contract is the shared understanding of how an API should behave and how that behavior is communicated, including clarification of endpoints and error codes. This contract is usually formed by an autogenerated API specification that documents the API ahead of its inception.
By creating a single or a series of API contracts within your organization, you not only are enforcing the quality and compliance of your APIs, you are speeding up development time through API reusability. That means your developers can focus on more creative work and the delivering of value. And, by creating that shared understanding among stakeholders, you create more consistent value for all.
Platform-based API governance should include:
- Program governance through predefined best practices.
- Design governance through templates and the API specification.
- Platform governance through the runtime platform or studio.
An API contract also can exist in different versions because that behavior and the corresponding contract will likely change along with updates. Versioning, again, should be enforced by the platform, not the team.
Governance is inherently enforcing consistency across hundreds, thousands, or even hundreds of thousands of cross-organizational APIs via a platform. API governance cannot be achieved by manual review.
Poor API Governance Is Your Biggest Security Risk
Forrester found that 77% of organizations both develop and consume APIs. The internet and your business value are more connected than ever, with data and services living in real time, necessarily meeting customer demands. This interconnectivity also puts your services more at risk than ever by broadening your attack vector. In fact, Gartner pegged APIs as 2022’s primary attack vector. To top that, Salt Security found a 681% increase in API attacks in 2021.
Enterprises are bearing the PR and financial cost of these data breaches. IBM’s Cost of a Data Breach Report 2021 found that the average cost of a breach was $4.24 million, with it taking 287 days for respondents to even identify that they’ve been breached. With about 70% of organizations leveraging open source, this time to fix is underscored with Sonatype’s State of the Software Supply Chain Report uncovering that the meantime to remediate an open source security vulnerability is 326 days.
Without platform-based governance, the time and cost of repair across your API sprawl is staggering. Fortunately, the same IBM report found that automation is the single most important way to prevent these breaches. API governance is automating that consistency across your organization. And it’s about creating security patterns and appointing them to compliance and inner-company and industry standards.
When API Governance Is MIA
Much of my time in the API space is selling Apigee (before and after the Google acquisition) to enterprise customers, helping them with their cloud strategy and digital transformation roadmap. These were typically telecommunications providers, banks and financial services, and other Fortune 500 companies in the U.S. and APAC.
My role helped them to identify where they are and where they wanted to go and to reflect on their problem statements, before guiding them through the implementation of Apigee as their API management. Together, we were able to solve their runtime challenges; however, there was still downtime due to a lack of API governance. The highest level of governance most organizations I consulted with had was role-based access control.
Time and again, these organizations would run vulnerability scans post deployment — and, most embarrassingly, often external third-party partners would find these vulnerabilities, which included unauthenticated services. At a bank, this lack of API lifecycle governance could actually prevent them from getting the essential PCI-DSS payment certification.
A telco provider received feedback from third-party integration partners that APIs from different teams didn’t even look like they came from the same company. One team called the same answer “user” while another called it “client.” Yes, certifications matter, but so does maintaining a basic level of hygiene so that different terms and error codes don’t come back from the same company.
Governance is about automating and enforcing this consistency — including compliance and security — through the whole API lifecycle. Ideally, this is all in place well before you look to externalize or monetize anything. Google refers to this as API Governance 2.0, where you don’t expose anything without thinking about security and consistency first.