It is increasingly challenging for developers and security teams to keep the application-development process and application programming interfaces (APIs) secure. But there is no single standard for managing APIs and, thus, teams cannot rely on tools alone to solve security issues. No single product can fix every problem for every language, framework, or context of an API environment.
So enterprises play mix-and-match. Modern organizations are fixated on tools to respond to their cyberthreat challenges—to the point of lapsing into tunnel vision that impedes progress. A 2022 report showed that large-enterprise security teams oversaw an average of 76 security tools. That’s far too many.
The focus on security software creates a false sense of security and a failure to address underlying causes. Most data breaches are caused by human error. Our research has found that developers heavily rely upon pre-existing code, for example—with nearly one-half using libraries or frameworks with inherent flaws because they are not tested or evaluated on an ongoing basis for vulnerabilities. To wit, developers assume that because the code exists in a library, it is secure. But this is not always the case.
That’s why we need to press the reset button. We need to stop constantly seeking the latest shiny object and start focusing more on our people. Yes, security tools have advanced impressively and serve a critical purpose. But software development teams still need to improve their security capabilities to effectively deploy these solutions. The resulting training and policy implementation should focus on the following best practices:
Assign API Ownership
By their very nature, APIs are over-permissioned to allow unchecked communications between applications. Frankly, they “talk too much”—leading to a state of oversharing that triggers compromises. We call this “TMI tech.”
TMI tech persists because we rarely assign ownership of APIs (either to developers or to their app sec cohorts). Accordingly, there is rarely any meticulous monitoring of which API is sharing what.
To rectify this, managers should assign API ownership to development teams and help them recognize the risks of wide-open (and undocumented) API implementation. When such responsibilities are covered and contextual behavioral baselines are established, it is far easier to shut down these troublesome “conversations.”
Treat APIs Like Humans
To extend our first best practice, we can immediately improve access control by applying zero-trust, least-privilege, and role-based authorization to APIs, just as we do with people. If an API is required to perform a specific function, then we limit its permissions to that function only. Similarly, we should further restrict APIs’ time spent accessing—and the volume accessed—as appropriate.
Incorporate a Test-First Mentality
Developers need to understand the pitfalls of assumption—but preferably not the hard way. As such, dev teams should regularly test APIs to verify that they are not exploitable (while still functioning as intended). Testing early and often can help reduce bugs, saving time and additional costs in the long run. Plus, security teams will appreciate it.
Include Scenario Simulations
Simulations better equip developer teams to react when different API situations play out. And they seem to be exactly what developers need to improve their secure-coding skills. Research conducted by Secure Code Warrior found that more than nine out of every ten developers acknowledged needed training in security frameworks. Almost a third (30%) reported feeling that they would benefit from practical security-training sessions featuring work-relevant, real-life examples; nearly as many indicated that they would benefit from hands-on interactivity—such as practice sessions in which they attempt to write secure code.
Change Performance-Review Metrics
Secure development cannot be rushed. Given the clear consequences, therefore, it is time to cease placing so much emphasis during team-member evaluations on raw speed of feature delivery. Otherwise, the performance-review phase presents developers with a perverse incentive to sacrifice security (if not quality). Instead, organizations should look to reward those who can create quality, secure code within a reasonable time frame.
A state of optimal protection remains a moving target as attack trends continue to shift rapidly. Application development and API management prove no exception. When we press the reset button to encourage a people-centric focus on secure development, backing it up with comprehensive policy implementation and best practices, we ensure that security is embedded into the development process—instead of being viewed as a roadblock to innovation.
