forked from MrRefactoring/jira.js
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathvulnerability.ts
77 lines (77 loc) · 2.95 KB
/
vulnerability.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
/**
* Data related to a specific vulnerability in a specific workspace that the vulnerability is present in. Must specify
* at least one association.
*/
export interface Vulnerability {
/**
* The VulnerabilityData schema version used for this vulnerability data.
*
* Placeholder to support potential schema changes in the future.
*/
schemaVersion: string;
/** The identifier for the Vulnerability. Must be unique for a given Provider. */
id: string;
/**
* An ID used to apply an ordering to updates for this Vulnerability in the case of out-of-order receipt of update
* requests.
*
* This can be any monotonically increasing number. A suggested implementation is to use epoch millis from the
* Provider system, but other alternatives are valid (e.g. a Provider could store a counter against each Vulnerability
* and increment that on each update to Jira).
*
* Updates for a Vulnerability that are received with an updateSqeuenceId lower than what is currently stored will be
* ignored.
*/
updateSequenceNumber: number;
/** The identifier of the Container where this Vulnerability was found. Must be unique for a given Provider. */
containerId: string;
/**
* The human-readable name for the Vulnerability. Will be shown in the UI.
*
* If not provided, will use the ID for display.
*/
displayName: string;
/** A description of the issue in Markdown format. Will be shown in the UI and used when creating Jira Issues. */
description: string;
/**
* A URL users can use to link to a summary view of this vulnerability, if appropriate.
*
* This could be any location that makes sense in the Provider system (e.g. if the summary information comes from a
* specific project, it might make sense to link the user to the vulnerability in that project).
*/
url: string;
/** The type of Vulnerability detected. */
type: string;
/**
* The timestamp to present to the user that shows when the Vulnerability was introduced.
*
* Expected format is an RFC3339 formatted string.
*/
introducedDate: string;
/**
* The last-updated timestamp to present to the user the last time the Vulnerability was updated.
*
* Expected format is an RFC3339 formatted string.
*/
lastUpdated: string;
/**
* Severity information for a single Vulnerability.
*
* This is the severity information that will be presented to the user on e.g. the Jira Security screen.
*/
severity: {
/** The severity level of the Vulnerability. */
level: string;
};
/** The identifying information for the Vulnerability. */
identifiers?: {
/** The display name of the Vulnerability identified. */
displayName: string;
/** A URL users can use to link to the definition of the Vulnerability identified. */
url: string;
}[];
/** The current status of the Vulnerability. */
status: string;
/** The entities to associate the Security Vulnerability information with. */
associations?: {}[];
}