Evidence collection for Releases - snapshot of release metadata at moment of release creation
Problem to solve
As part of the need to comply with different SDLC and security standards, we wish to provide the users with the data needed in order to serve as evidence of the SW chain of custody.
The data already exists within Gitlab but we want to make it easy to find and presentable for the users.
Target audience
Release Managers, compliance and security teams
Further details
In order to prove (for example in an audit), that the release version is consistent over time, many times the checksum is needed. SHA256/SHA512 is usually used (MD5 is not as secure)
Commit-ish/Tree-ish | Examples |
---|---|
1. <sha1>
|
dae86e1950b1277e545cee180551750029cfe735 |
2. <describeOutput>
|
v1.7.4.2-679-g3bee7fb |
3.<refname>
|
master, heads/master, refs/heads/master |
4. <refname>@{<date>}
|
master@{yesterday}, HEAD@{5 minutes ago} |
5. <refname>@{<n>}
|
master@{1} |
6. @{<n>}
|
@{1} |
7. @{-<n>}
|
@{-1} |
8. <refname>@{upstream}
|
master@{upstream}, @{u} |
9. <rev>^
|
HEAD^, v1.5.1^0 |
10. <rev>~<n>
|
master~3 |
11. <rev>^{<type>}
|
v0.99.8^{commit} |
12.<rev>^{}
|
v0.99.8^{} |
13. <rev>^{/<text>}
|
HEAD^{/fix nasty bug} |
14. :/<text>
|
:/fix nasty bug |
Proposal
Add new kind of entity called evidence
to releases. These entities should contain the raw materials, not links, and should include a strong checksum gathered at the time the release was created to ensure they cannot be tampered with later.
For the first iteration (release 12.4), we will provide:
- A snapshot of the release JSON and its SHA256 for the current source code associated with the tag. The content will include details of the release, the associated milestones, the project, and related issue details. Here's is the the release 12.6 JSON:
{
"release": {
"id": 5,
"tag": "v4.0",
"name": "New release",
"project_id": 45,
"project_name": "Project name",
"released_at": "2019-06-28 13:23:40 UTC",
"milestones": [
{
"id": 11,
"title": "v4.0-rc1",
"state": "closed",
"due_date": "2019-05-12 12:00:00 UTC",
"created_at": "2019-04-17 15:45:12 UTC",
"issues": [
{
"id": 82,
"title": "The top-right popup is broken",
"author_name": "John Doe",
"author_email": "john@doe.com",
"state": "closed",
"due_date": "2019-05-10 12:00:00 UTC"
},
{
"id": 89,
"title": "The title of this page is misleading",
"author_name": "Jane Smith",
"author_email": "jane@smith.com",
"state": "closed",
"due_date": "nil"
}
]
},
{
"id": 12,
"title": "v4.0-rc2",
"state": "closed",
"due_date": "2019-05-30 18:30:00 UTC",
"created_at": "2019-04-17 15:45:12 UTC",
"issues": []
}
]
}
}
- A link to the external location of the *.exe or installation file of the build/release: (the link itself is not strong enough to be evidence, but can help find it easily during in audit)
"links":[ { "id":3, "name":"hoge", "url":"https://google.com", "external":true }
Future Considerations
- In a later phase we will research how we can get the actual checksum of the installation file, image and package.
UX Proposal
- Add the evidence JSON and SHA (a record that will identify revisions and to ensure that the data has not changed due to accidental corruption) under the
Assets
section of a Release -evidence_url
- User sees the JSON
evidence_url
. Clicking on it download the file. - Next to the JSON, a short version of the SHA should be displayed. Clicking on the ellipsis icon next to it expand it to display the full SHA.
- A button to copy the SHA to the clipboard should be available. Hovering it displays a tooltip that reads
Copy SHA to clipboard
. After the user clicks the button, the full SHA should be copied to the clipboard, and the tooltip text should change toCopied
.- This behaviour is similar to what is current implemented in the Pipeline detail view. See example here: https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/pipelines/84635941/?project_id=4456656&page=1&days=90
Page view | Prototype |
---|---|
JSON and SHA displayed in a Release | |
SHA is expanded | |
Copy SHA | |
Sha is copied to clipboard |
Permissions
- Release evidence should follow the same permissions as Release data, in that permissions for the data should only be accessed by those with access.
What does success look like, and how can we measure that?
- With the availability to see a snapshot, we should expect to see and increase in MAU of releases