API Management: Using Runtime API Security to Enhance API Lifecycle Processes

Address API security across the entire API lifecycle.

API Management and Security

As I look at the range of API Management approaches that are recommended by various analysts, pundits, and vendors, I find it interesting that most don’t really know how to address “security” in the context of API management. In high-level API lifecycle management diagrams securing APIs is rarely called out visually, although it may be addressed briefly in an accompanying paragraph.


In more detailed API lifecycle diagrams, security is given its own box or step, but it’s often positioned as a “check off” item following deployment (that’s right, according to some recommended approaches, you secure an API AFTER you deploy it! Go figure…). It’s especially disheartening when the security block in an API lifecycle flow is shown as an afterthought, at the end of the flow, just before the “decommission” or “retire” block.


In reality, API security needs to be addressed as an overriding theme across the entire API lifecycle, and unfortunately, this is where most approaches to API lifecycle management fail. In fact, if done correctly, API security can enhance many other aspects of the API management lifecycle

Security: A Foundational Theme That Enhances API Management

I could go through every element of a detailed API lifecycle process and show why security can and should be included in each, but I think a few examples will suffice:


As an organization moves to an API/microservices-centric approach to software delivery, there may be aspirations, expectations, commitments, etc. that might not line up with reality. Including security as part of the strategy discussions can add a sense of grounding/reality into the mix, resulting in a more effective strategy.


Successful API-centric organizations include security in their designs. However, their security designs do not always keep pace with the current security challenges the deployment and monitoring teams face.


Those who adopt a test-driven design (TDD) mindset are good at translating business requirements into tests well before the coding starts. However, do they include security requirements in the process? How often is security test development included alongside business tests?


Loads of resources are allocated to API tracing, observability, monitoring, etc., but are any of these tied or aligned to security? Or is that “someone else’s job”? Teams that include a security mindset as they implement their app/API monitoring capabilities find that expanding the intersection of operational monitoring and security monitoring can lead to a range of dividends, including a better understanding of how attacks are impacting important KPIs such as latency, resource utilization, response times, user satisfaction, etc.

Runtime Security as Critical Feedback for API Management

One of the most useful lessons I learned in engineering school was the importance of reducing the delay between sending/receiving feedback and making adjustments – it’s so critical in keeping a system stable while progressing towards the desired goal. Interestingly, I’ve discovered it’s a principle that has just as much application in business as it does in technology. When applied to API management, this principle can make many aspects of API management more effective while bringing the whole of the effort towards a more desired state.

The popularity of the CI/CD paradigm has resulted in a huge investment of time, money, and resources to enable teams to release a constant flow of software updates into production, with the goal to quicken release cycles, lower costs, and reduce the risks associated with development. This model has become a critical, central part of the overall API lifecycle effort, to the point that many API lifecycle management approaches look almost like a CI/CD cycle. Unfortunately, “security” didn’t make the cut as far as getting its own block or some agreed-upon presence in most representations of the CI/CD model.


The “infinity loop” representation of the CI/CD process implies a level of feedback in the overall process. Still, the representation doesn’t show the potential for having runtime security feeding back quickly into multiple points of the process, as discussed above. Here is an updated representation showing where runtime API security information can be routed back to parts of the CI/CD process.


This approach provides an immediate awareness of runtime security issues that need to be addressed upstream (design, test) or in parallel (operation, monitoring). Runtime API security solutions can immediately send alerts, contextual histograms/charts, detailed security event data, etc. to assist in every aspect of API management. Because this security-centric feedback is received in near real-time, the overall API management process responds quickly to security events/trends and in a direction, that enhances the overall security of the organization’s APIs and the critical processes and applications that depend on them.


If you want to see how runtime API security can help you achieve higher levels of security and a more effective API management process, contact us today at Graylog.

Get the Monthly Tech Blog Roundup

Subscribe to the latest in log management, security, and all things Graylog blog delivered to your inbox once a month.