Secure / Govern sub-department delineation

Why does this page exist?

In the spirit of establishing a DRI for each set of functionality where this may not be obvious, the purpose of this page is to explicitly define which engineering group has reponsibility for which portions of the product and for specific decisions.

Page/Function responsibilities

Page/Function	PM	Primary Group	Example
Secure Partner Onboarding Docs	Alana Bellucci	Sec by their categories
Security Configuration		Sec by their categories
Vulnerability ingestion and DB storage	Alana Bellucci	Govern:Threat Insights
Dependency ingestion and DB storage	Alana Bellucci	Govern:Threat Insights
Dependency List	Alana Bellucci	Govern:Threat Insights	Example
License Compliance Page	Alana Bellucci	Govern:Threat Insights
Interact with findings and vulnerabilities	Alana Bellucci	Govern:Threat Insights
Merge Request Security Widget	Alana Bellucci	Govern:Threat Insights	Example
Merge Request License Compliance Widget	John Crowley	Secure:Composition Analysis	Example
Pipeline Security Tab	Alana Bellucci	Govern:Threat Insights	Example
Security Dashboards	Alana Bellucci	Govern:Threat Insights	Example
Security Scanner Integration Documentation	Alana Bellucci	Govern:Threat Insights
Vulnerability Pages	Alana Bellucci	Govern:Threat Insights	Example
Vulnerability Report	Alana Bellucci	Govern:Threat Insights	Example
Policies	Grant Hickman	Govern:Security Policies	Example
Advisories ingestion and DB storage	John Crowley	Secure:Composition Analysis
External License ingestion and DB storage	John Crowley	Secure:Composition Analysis
Vulnerability Match Job	John Crowley	Secure:Composition Analysis
License Match Job	John Crowley	Secure:Composition Analysis
CVE ID Request - Workflow and automation	Sarah Waldner	Secure:Vulnerability Management
CVE ID Request - Platform UI	Alana Bellucci	Govern:Threat Insights

Technical Boundaries

Ownership of the end-to-end technical solution spans multiple groups. This section clarifies cross-group maintainership of code artifacts between Threat Insights and the remaining groups in the Sec Section.

Ownership means that the responsible group:

1. Is responsible for maintenance of the code.
2. Receives attribution in their error budget associated with the relevant code.
3. Must be consulted before changes are made, and should review them before being merged.
4. Receives priority when requesting maintenance and fixes to changes introduced by another group.

Owners by project/function

This is not a comprehensive list, but includes the main projects and areas of functionality under the Sec Section umbrella.

Comparison and tracking logic

The logic to compare and track vulnerabilities is owned by Threat Insights.

Customisation of this logic that is not generic to all report types is owned by the corresponding group(s) (e.g. Static Analysis group would be the maintainer of any improvement to track SAST vulnerabilities).

It is not always possible to promptly identify the group that owns some code. In the absence of an attribution through error budget, CODEOWNERS, code comments or other means, Threat Insights will idenfity the owner and, if necessary, handover to the appropriate group.

Security Report Schema

The schemas are owned by the backend team in the analyzer groups responsible for the corresponding categories.

Threat Insights owns the base schema and the generic details schema.

For instance, the Static Analysis group is responsible for the SAST category, so its backend team is responsible for the sast report JSON schema.

Regardless of ownership, Threat Insights must review all changes as they are the consumer of reports that conform to the schemas.

For more information on who to request a review from, see the project guidelines.

Vulnerability Management

This includes all items assigned to Threat Insights under Page/Function responsibilities, and also:

• Database Management System objects
• Object-relational mappings
• Integration points
  • APIs
  • Security report ingestion framework

View page source - Edit this page - please contribute.