| Application ID | The application ID associated with the finding. |
| Archived by Sandbox Expiration (Yes / No) | The flag to denote if Veracode archived the finding and deleted the scan from view due to sandbox scan expiration. Use this flag to filter in or out findings that only existed in archived scan data. Findings that exist in non-archived scan data is not considered archived. |
| Component Path | The custom name and severity of the library at the time of the build of the compilation of the application. |
| Custom Severity | The user-created severity for the finding. Located fromPolicy > Policies > Custom Severities. |
| Custom Severity Description | The description for the finding with user-created severity. |
| Custom Severity Name | The name of the severity of the finding. Values are Informational, Very Low, Low, Medium, High, or Very High. |
| CWE ID | The ID and the name of the common weakness enumeration (CWE) found after the application was scanned. |
| Description | Provides a brief description of the finding. For a category description, see the CWE Description dimension. |
| Dynamic Findings - General | Contains: - Path: Provides the URL path where Dynamic Analysis discovered the vulnerability.
- Vulnerable Parameter: The specific injection point that identifies the vulnerability discovered by Dynamic Analysis. Examples include cookies, query strings, and POST body data. Not all vulnerabilities have a vulnerable parameter.
|
| Exploitability | The rating for the likelihood that an attacker could exploit the finding. |
| Exploitability Description | The description for the likelihood that an attacker could exploit the finding. |
| Fixable (Yes / No) | Determines if a finding could be resolved using Veracode Fix. |
| Fixed Date | The date a finding was closed because it was no longer present in the scan results for the application. |
| Finding Status | The status of the finding. Values are Open or Closed. |
| First Found Date | Very first overall occurrence of the finding in a given context. In most cases, First Found in Application Date should be used.
For SCA upload scan findings, this is the latest of either: - A vulnerable library was scanned in a given context.
- A CVE was published for a previously in-use library.
For application-linked SCA agent-based findings, this is the latest of either: - A vulnerable library was scanned in a linked project.
- A CVE was published for a previously in use-library.
You can filter by Date, Month, Quarter, Time, Week, Year. |
| First Found in Application Date | Very first overall occurrence of the finding in either sandbox or policy. In most cases, First Found in Application Date should be used.
For Upload SCA findings, this is the latest of either: - A vulnerable library was scanned in a given context.
- A CVE was published for a previously in-use library.
For application-linked SCA agent-based findings, this is the latest of either: - A vulnerable library was scanned in a linked project.
- A CVE was published for a previously in-use library.
You can filter by Date, Month, Quarter, Time, Week, Year. |
| Flaw Age | The range between the Finding Found Date and Finding Resolved Date dimensions. If the resolved date is null, use today's date. |
| Flaw Age Tier | The length of time by days the finding was open. Values are 1, 7, 30, or 90 days. |
| Flaw ID | The ID of the finding on the Veracode Platform. |
| Grace Period Expiration Date | The date on which a grace period expires for the finding. Veracode calculates this date based on the last date a finding was opened (First Found or Last Reopened date), and based on the grace period provided in the security policy assigned to the application. This date only applies to open findings that impact policy compliance. |
| Last Found Date | The date the finding was last found. You can filter by Date, Month, Quarter, Time, Week, Year. |
| Last Updated Date (Reporting API only) | Used for incremental reporting of findings data in the Reporting API. This date is the latest date of the following data points: First Found Date, Last Found Date, Resolved Date, Most Recent Mitigation Action Date, and timestamp of any application-level changes (e.g., Application Name changed, Business Unit changed, Policy changed). |
| Library First Found in Active Scans | The earliest date of a scan where this library was found. This date can be later than when the Veracode SCA tool detected a vulnerability because you may have archived or deleted earlier scans with that library. |
| Mitigation Status | The mitigation status for the finding. Values are Proposed, Accepted, Rejected, or Not Mitigated. Provides the latest mitigation workflow status for a mitigation on a finding. |
| Module Name | The name of the module in which the finding was seen. |
| Most Recent Mitigation Details | The fields in this menu include the most recent mitigations details for:- Acceptance Comment - the comment provided with the most recent acceptance action on a mitigation proposal.
- Acceptance Date - date the most recent mitigation proposal was accepted.
- Acceptance Time - time the most recent mitigation proposal was accepted.
- Accepter Username - name of the person who accepted the most recent mitigation proposal.
- MPR Comment - comment provided by Veracode in the most recent Mitigation Proposal Review of a mitigation proposal.
- MPR Date - date of the most recent occurrence of a Mitigation Proposal Review for this mitigation proposal.
- MPR Status - determines whether or not the finding conforms to the risk tolerance guidelines established by your organization.
- MPR Time - time of the most recent occurrence of a Mitigation Proposal Review for this mitigation proposal.
- MPR Username - Veracode provides Mitigation Proposal Reviews as a service to offer guidance on validity, propriety, and effectiveness of mitigation proposals according to the risk tolerance guidelines of your organization. Veracode is always the username returned in this field.
- Proposal Comment - comment provided with the most recent mitigation proposal.
- Proposal Date - date the most recent mitigation proposal was made.
- Proposal Time - time the most recent mitigation proposal was made.
- Proposer Username - username of the user who provided the most recent mitigation proposal.
- Rejecter Username - username of the user who rejected the most recent mitigation proposal.
- Rejection Comment - comment provided with the rejection of the most recent mitigation proposal.
- Rejection Date - date of the most recent rejection the most recent mitigation proposal was rejected.
- Rejection Time - time the most recent mitigation proposal was rejected.
|
| New Finding (Yes/No) | Determines if the finding is new. Values are Yes or No. |
| Policy or Sandbox Scan | Determines if the finding is in a policy or sandbox scan. |
| Policy Rule Passed (Yes/No) | Determines if a finding passed policy. For open findings or mitigated closed findings, this is determined by the current policy attached to the application. For closed fixed findings, this is determined by the version of the policy that was attached at the time the finding was closed. Values are Yes or No. |
| Policy Status | Evaluation of whether the finding has passed, failed, or conditionally passed (rule failed but within grace period) policy. |
| Reopened Date | The date a finding was reopened. A finding can be reopened if it was previously fixed, then found in a later scan in the same context again. You can filter by Date, Month, Quarter, Time, Week, Year. |
| Reopened Finding (Yes/No) | Determines if the finding is a reopened finding. |
| Resolved Date | The date a finding was closed either through remediation, indicating the finding is no longer available in the results, or through a mitigation or resolution workflow that has been approved. You can filter by Date, Month, Quarter, Time, Week, Year. |
| Sandbox Name | The name of the sandbox scan in which the finding was found. |
| Scan Type | The type of scan that produced this finding. Values are Dynamic, Static or Manual Penetration Test. |
| Second Party Component | The name of the second party component used by the module in which the finding was seen. |
| Static Findings - General | Contains: - Attack Vector: the location of the flaw (the sink) discovered by Static Analysis in the function call, as seen in the Triage Flaws view of the Veracode Platform.
- Class Path: the full name of the class path containing the finding, as seen in the Data Path details page in the Triage Flaws view of the Veracode Platform.
- Filename/Class: the filename or class in which Veracode discovered the static finding. This value is combined with the line number in the Source field in the Triage Flaws view of the Veracode Platform.
- Function Name: the name of the function in which Veracode discovered the static finding. This value replaces the filename in the Source field of the Triage Flaws view in the Veracode Platform when you compile and upload the modules without debug symbols.
- Most Recent Line Number: in the most recent static scan, this value is the line number in which Veracode discovered this finding, or the relative location in the function that contains the finding.
|
| Submodule Path | Secondary party module information. |
| Unique to a Single Context (Yes/No) | A finding is unique and has only been seen in a single sandbox or policy context within an application. |