I am working through the almost 100 federal government agency developer portals and the almost 500 APIs that exist across these agencies, looking for the good and bad of APIs in government at this level. One of interesting building blocks I’ve stumbled across, that I would like to shine a light on for other public and private sector API providers to consider in their own operations is a vulnerability disclosure.
I feel that 18F description of their vulnerability disclosure says it best:
As part of a U.S. government agency, the General Services Administration (GSA)’s Technology Transformation Service (TTS) takes seriously our responsibility to protect the public’s information, including financial and personal information, from unwarranted disclosure.
We want security researchers to feel comfortable reporting vulnerabilities they’ve discovered, as set out in this policy, so that we can fix them and keep our information safe.
This policy describes what systems and types of research are covered under this policy, how to send us vulnerability reports, and how long we ask security researchers to wait before publicly disclosing vulnerabilities.
This should be default across all federal, state, county, and municipal government agencies. Hell, it should be default across all companies, organizations, and institutions. One of the reasons we have so much dysfunction in the security realm that elevates the discussion to theatrical levels with cybersecurity is that we aren’t having honest conversations about the vulnerabilities that exist. Few platforms want these conversations to occur, let alone set the tone of the conversation in such an open way. Without any guidance, and fear of retaliation, developers and analysts who find vulnerabilities will continue to hold back on what they find.
Vulnerability disclosure seems like something that ALL API provides should possess. There is no reason you can’t fork the GSA vulnerability policy and share it as the official tone of the vulnerability disclosure conversation on your platform. Encouraging all API developers to understand what the tone of the conversation will look like when they stumble across a vulnerability while integrating with your API. I’m adding the concept of having a vulnerability disclosure to my API vulnerability research, and I am going to add GSA’s version as a tool in the API vulnerability toolbox, providing a template that other providers can put to work.
