API to add additional content to security dashboard
Problem to solve
Teams and partners perform additional scanning on user commits and repositories to provide various information. Today, they must then communicate this information in GitLab comments, create issues, or direct users to a different dashboard. This produces friction because GitLab users are already using the Security Dashboard experience to view security, scanning, and compliance results.
Additionally, because the Security Dashboard is owned and built by a single team, it can be difficult to coordinate additions to it.
Intended users
- Parker (Product Manager)
- Sidney (Systems Administrator)
- Sam (Security Analyst)
- Partners who wish to integrate their own solution with GitLab
Further details
Because GitLab wants to play well with others, building intentional integration touch points help everyone to contribute to GitLab and means we don't have to spend as much time on bespoke development.
Consider how teams at GitLab could use this API to add additional functionality or conduct product experiments.
Proposal
Expose an API to add additional blocks of content or screens to the Security Dashboard.
Minimal
- An API exists which can provide information to be display on the Security Dashboard
- The API should accept a name for the information to be displayed (e.g.
Sam's Deluxe Custom Scanner
) - The API should accept an image (e.g. logo for the scanner)
- The API should accept arbitrary text (e.g. the results of the scan)
- The API should accept a status emblem image (e.g. green check or red x for success & failure)
-
Work with team & field to refine required information & structure for what the API accepts & displays
- The API should accept a name for the information to be displayed (e.g.
- Display information provided via the API on the Security Dashboard
- Display in addition to other information on the Security Dashboard, not instead of.
- Information is only updated when new data is pushed to it by the 3rd-party. It is not done with a polling mechanism.
- GitLab admin users can enable/disable content that is added using the API
- Integrations should require that an admin has explicitly allowed the integration to add results.
-
Discuss this in more depth with the team. Perhaps require an access token or similar with each requests? Do we already do something like this in other APIs we could build off of, such as the Settings->Integration
tab?
- Usage analytics information is recorded for the integration
- Record each individual call to the APIs and sum the counts.
-
Anything else?
Next steps / follow-ons
- The API can accept a URL to display an
<iframe>
of content- Goal here is to allow richer content. Non-
<iframe>
solutions are possible.
- Goal here is to allow richer content. Non-
- The content can be displayed in an MR
- Consider moving this to a new issue as it sounds like it's own experience.
Permissions and Security
- Users are required to have access to the Security Dashboard to see the content
- Users are required to be GitLab admins to either enable or disable integration APIs for their instance
- Input is sanitized before being displayed
- API callers are required to show they are a valid API caller, with a token or similar
Documentation
- API versioning
- Forward/backwards-compatibility
Testing
- Performance testing
- Synchronous / asynchronous API
- Caching of responses
What does success look like, and how can we measure that?
- Number of partners using the API within 3 months of release. Target => 3
- Number of GitLab-developed features using the API within 12 months of release. Target => 6