---
title: "Submit Vulnerability data"
method: POST
path: "/rest/security/1.0/bulk"
tags: ["Security Information"]
---

# Submit Vulnerability data

`POST /rest/security/1.0/bulk`

Update / Insert Vulnerability data.

Vulnerabilities are identified by their ID, any existing Vulnerability data with the same ID will be replaced if it exists and the updateSequenceNumber of the existing data is less than the incoming data.

Submissions are performed asynchronously. Most updates are available within a short period of time but may take some time during peak load and/or maintenance times. The GET vulnerability endpoint can be used to confirm that data has been stored successfully (if needed).

In the case of multiple Vulnerabilities being submitted in one request, each is validated individually prior to submission. Details of Vulnerabilities that failed submission (if any) are available in the response object.

A maximum of 1000 vulnerabilities can be submitted in one request.

## Request body

- object — The payload used to submit (update / insert) Vulnerability data.
  - `operationType` 'NORMAL' | 'SCAN' | 'BACKFILL' — Indicates the operation being performed by the provider system when sending this data. "NORMAL" - Data received during real-time, user-triggered actions (e.g. user closed or updated a vulnerability). "SCAN" - Data sent through some automated process (e.g. some periodically scheduled repository scan). "BACKFILL" - Data received while backfilling existing data (e.g. pushing historical vulnerabilities when re-connect a workspace). Default is "NORMAL". "NORMAL" traffic has higher priority but tighter rate limits, "SCAN" traffic has medium priority and looser limits, "BACKFILL" has lower priority and much looser limits
  - `properties` object — Properties assigned to vulnerability data that can then be used for delete / query operations. Examples might be an account or user ID that can then be used to clean up data if an account is removed from the Provider system. Properties are supplied as key/value pairs, and a maximum of 5 properties can be supplied, keys cannot contain ':' or start with '_'.
  - `vulnerabilities` object[], required
    - `schemaVersion` '1.0', required — The VulnerabilityData schema version used for this vulnerability data. Placeholder to support potential schema changes in the future.
    - `id` string, required — The identifier for the Vulnerability. Must be unique for a given Provider.
    - `updateSequenceNumber` integer, required — 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 updateSequenceId lower than what is currently stored will be ignored.
    - `containerId` string, required — The identifier of the Container where this Vulnerability was found. Must be unique for a given Provider. This must follow this regex pattern: `[a-zA-Z0-9\\-_.~@:{}=]+(/[a-zA-Z0-9\\-_.~@:{}=]+)*`
    - `displayName` string, required — The human-readable name for the Vulnerability. Will be shown in the UI. If not provided, will use the ID for display.
    - `description` string, required — A description of the issue in markdown format that will be shown in the UI and used when creating Jira Issues. HTML tags are not supported in the markdown format. For creating a new line `\n` can be used. Read more about the accepted markdown transformations [here](https://atlaskit.atlassian.com/packages/editor/editor-markdown-transformer).
    - `url` string, uri, required — 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).
    - `type` 'sca' | 'sast' | 'dast' | 'unknown', required — The type of Vulnerability detected.
    - `introducedDate` string, date-time, required — The timestamp to present to the user that shows when the Vulnerability was introduced. Expected format is an RFC3339 formatted string.
    - `lastUpdated` string, date-time, required — The last-updated timestamp to present to the user the last time the Vulnerability was updated. Expected format is an RFC3339 formatted string.
    - `severity` object, required — 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.
      - `level` 'critical' | 'high' | 'medium' | 'low' | 'unknown', required — The severity level of the Vulnerability.
    - `identifiers` object[] — The identifying information for the Vulnerability.
      - `displayName` string, required — The display name of the Vulnerability identified.
      - `url` string, uri, required — A URL users can use to link to the definition of the Vulnerability identified.
    - `status` 'open' | 'closed' | 'ignored' | 'unknown', required — The current status of the Vulnerability.
    - `additionalInfo` object — Extra information (optional). This data will be shown in the security feature under the vulnerability displayName.
      - `content` string, required — The content of the additionalInfo.
      - `url` string, uri — Optional URL linking to the information
    - `addAssociations` object[] — The associations (e.g. Jira issue) to add in addition to the currently stored associations of the Security Vulnerability.
      - `associationType` 'issueIdOrKeys', required — Defines the association type.
      - `values` string[], required — The Jira issue id or keys to associate the Security information with. The number of values counted across all associationTypes (issueIdOrKeys) must not exceed a limit of 500.
    - `removeAssociations` object[] — The associations (e.g. Jira issue) to remove from currently stored associations of the Security Vulnerability.
      - `associationType` 'issueIdOrKeys', required — Defines the association type.
      - `values` string[], required — The Jira issue id or keys to associate the Security information with. The number of values counted across all associationTypes (issueIdOrKeys) must not exceed a limit of 500.
    - `associationsLastUpdated` string, date-time — An ISO-8601 Date-time string representing the last time the provider updated associations on this entity. Expected format is an RFC3339 formatted string.
    - `associationsUpdateSequenceNumber` integer — A sequence number to compare when writing entity associations to the database. This can be any monotonically increasing number. A highly recommended implementation is to use epoch millis. This is an optional field. If it is not provided it will default to being equal to the corresponding entity's `updateSequenceNumber`. Associations are written following a LastWriteWins strategy, association that are received with an associationsUpdateSequenceNumber lower than what is currently stored will be ignored.
  - `providerMetadata` object — Information about the provider. This is useful for auditing, logging, debugging, and other internal uses. Information in this property is not considered private, so it should not contain personally identifiable information
    - `product` string — An optional name of the source of the vulnerabilities.

## Response `202`

Submission accepted. Each Vulnerability submitted in a valid format will eventually be available in Jira.

Details of any Vulnerabilities that were submitted but failed submission (due to data format problems, etc.) are available in the response object.

- object — The result of a successful submitVulnerabilities request.
  - `acceptedVulnerabilities` string[] — The IDs of Vulnerabilities that have been accepted for submission. A Vulnerability may be rejected if it was only associated with unknown project keys. Note that a Vulnerability that isn't updated due to it's updateSequenceNumber being out of order is not considered a failed submission.
  - `failedVulnerabilities` object — Details of Vulnerabilities that have not been accepted for submission, usually due to a problem with the request data. The object (if present) will be keyed by Vulnerability ID and include any errors associated with that Vulnerability that have prevented it being submitted.
  - `unknownAssociations` object[] — Associations (e.g. Service IDs) that are not known on this Jira instance (if any). If a Vulnerability has been associated with any other association other than those in this array it will still be stored against those valid associations. If a Vulnerability was only associated with the associations in this array, it is deemed to be invalid and it won't be persisted.
    - `associationType` 'issueIdOrKeys', required — Defines the association type.
    - `values` string[], required — The Jira issue id or keys to associate the Security information with. The number of values counted across all associationTypes (issueIdOrKeys) must not exceed a limit of 500.

## Other responses

- `400` — Request has incorrect format. Note that in the case of an individual Vulnerability having an invalid format (rather than the request as a whole) the response for the request will be a 202 and details of the invalid Vulnerability will be contained in the response object.
- `401` — Missing a JWT token, or token is invalid.
- `403` — The app does not define a security info provider module, or does not have the required scope to access this resource.
- `413` — Data is too large. Submit fewer Vulnerabilities in each payload.
- `429` — API rate limit has been exceeded.
- `503` — Service is unavailable due to maintenance or other reasons.
- `default` — An unknown error has occurred.

---

[API](https://skmtc.net/atlassian/apis/jira-software-cloud-api.md) · [All operations](https://skmtc.net/atlassian/apis/jira-software-cloud-api/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/atlassian/jira-software-cloud-api/revisions/4e108d54b990/schema)