Using factors

In Veracode Risk Manager (VRM), factors work together to create a clear and complete picture of context. They are not limited to assets—some are specific to the conditions of an issue. Similarly, they are not limited to risk; some factors have no direct impact on risk scoring. Factors serve as foundational elements that support automated, bottom-up investigation, scoring, contextual analysis, discovery of new findings, and querying.

Each factor includes a summary, a detailed explanation, and insights that help you prioritize risks more accurately. Unlike raw attributes, factors are contextualized and require additional analysis. This analysis for defining factors is typically based on security best practices.

A factor provides the following information to help you understand more about what is being measured:

• A level (such as High, Medium, Low, or Unknown) to support consistent querying and reporting across different asset and issue types.
• Scoring details, including factor score, urgency, and severity scoring influences.
• A brief, user-friendly summary that explains the result at a glance.
• A detailed explanation describing what was analysed, how the analysis was done, and why the result matters.
• Reference links to documentation and articles for additional context and learning.

The following are a few examples of the factors that are used in VRM.

• Internet-Facing: indicates whether the asset is accessible from the public internet.
• Encryption: specifies whether data on the asset is encrypted or if encryption is enabled for data storage.
• Role permission level: determines how permissive the associated roles or access levels are. For example, the asset may have administrative access to the environment.

See Factor Descriptions to understand all the factors.

How factors influence scores in VRM

Factors provide the context needed to effectively prioritize risks. You can prioritize issues by severity and urgency scores, and prioritize assets by asset risk scores. All of these scores are significantly influenced by factors.

The final output is a prioritized list of issues, ranked by urgency. VRM uses these urgency scores to recommend the next best actions for the user.

Sources of factor data

In VRM, factor data is derived from the following sources:

• Asset source providers that include Cloud Service Provider (CSP) APIs
• Veracode security content library
• Finding source APIs
• External threat intelligence APIs

These sources provide the contextual data used to evaluate and prioritize risk.

Availability of factors for an asset

Most factors are associated with a specific asset type, for example, encryption of an AWS S3 bucket. Risk profiles are then built for assets based on factor results and then summarized to be comparable across different asset types. Other factors are associated with issues, for example, severity factors such as the existence of known public exploits for a vulnerability. These factors provide important security context for issues used when prioritizing based on urgency.

Assets that are more complex or pose a higher risk, such as cloud storage, are analyzed using more factors. Simpler assets, such as AWS Glue components, typically have fewer associated factors due to their lower risk impact.

Types of factors in VRM

In VRM, factors are categorized into two types based on where they are applied in the platform:

• Severity factors describe characteristics of an issue that are not specific to a particular asset—for example, conditions that are consistent across the industry for all assets affected by that issue.
• Urgency factors are specific to the particular asset in your organization's environment that is been assessed (e.g. is the asset internet-facing). They are used to build business context to determine how quickly an issue needs to be remediated.

Asset factors include just urgency factors. Issue factors include both severity and urgency factors.

Scoring model overview

VRM uses a scoring model that uses a predefined formula to calculate the final urgency score presented to the user. The original severity of an issue, as it enters the system, is referred to as the severity score. This score is derived from severity factors. Severity factor details are available on the CVEs, typically located at the bottom of the page.

View factors in assets

Use factors to prioritise mitigation of risks by assets.

To complete this task:

1. Log in to VRM.
2. Select the Assets icon .
3. Select an asset to view detailed information. Alternatively, you can use the filters to narrow your search results and then select a required asset.
4. The ASSET DETAILS page opens. On the asset details page, you can view the ASSET RISK score.
5. Select Factors. You can view the list of all factors assigned to the asset.

6. To view critical information regarding the factor, select it. The FACTOR DETAILS side drawer opens. Here, you find the following information:

   • DESCRIPTION: this section provides a summary of the selected factor.

   • FACTOR RESULTS: this section displays the data used to evaluate the factor. This information is either:

     • pulled directly from source APIs, or
     • retrieved from source APIs and then further analyzed by Veracode

     The purpose of this data is to provide transparency and evidence for how and why a factor was assigned its specific level. It helps users understand the rationale behind the factor’s impact on the overall score.

   • SCORING DETAILS: provides information about the scoring system used to determine asset risk levels or issue severity levels.

View factors in issues

Use factors to prioritise mitigation of risks by issues.

To complete this task:

1. Log in to VRM.
2. Select the Issues icon .
3. Select an issue to view detailed information. Alternatively, you can use the filters to narrow your search results and then select a required Issue.
4. The ISSUE DETAILS page opens. On the issue details page, you can view the urgency score.
5. Select Factors. You can view the list of all factors assigned to the issue.

6. To view critical information regarding the factor, select it. The FACTOR DETAILS side drawer opens. Here, you find the following information:

   • DESCRIPTION: this section provides a summary of the selected factor.

   • FACTOR RESULTS: this section displays the data used to evaluate the factor. This information is either:

     • pulled directly from source APIs, or
     • retrieved from source APIs and then further analyzed by Veracode

     The purpose of this data is to provide transparency and evidence for how and why a factor was assigned its specific level. It helps users understand the rationale behind the factor’s impact on the overall score.

   • SCORING DETAILS: provides information about the scoring system used to determine asset risk levels or issue severity levels.

Factor descriptions

The table below lists all the factors with their descriptions.

Factor	Description
Access Authentication	Access authentication level is based on whether multi-factor authentication is required, a strong password policy is in place, and whether additional access-limiting controls—such as IP address restrictions or conditional access policies—are implemented.
Account Value	Customer-defined value for the whole account. This can be derived from a tag on the account itself or provided manually by the user in Longbow.
Anomalies: Access	IoC count over a specified time period related to access anomalies.
Anomalies: Exfiltration	IoC count over a specified time period related to data exfiltration anomalies.
Anomalies: Privilege Escalation	IoC count over a specified time period related to privilege escalation anomalies.
Asset Members Count	Associates the number of assets or logical units contained within the asset. For example, the number of users in a group or the number of compute instances in a subnet.
Asset State	Tracks whether an asset is provisioned, deprovisioned, or in an intermediate provisioning state.
Asset Value	The asset value is either computed or configured directly through tags during account onboarding.
Authorized Entity Count	An asset's authorized entity count tracks the number of principals or other assets that can access it. For example, the number of users that can assume a role or execute a serverless function.
Cross Tenant Object Replication	Indicates whether cross-tenant object replication is enabled for a particular storage account.
CVEs Count	The total count of CVEs across all software packages on the asset.
Asset Has Secrets	Indicates whether an asset stores secrets—for example, if a storage bucket contains private keys or if API keys are stored within Lambda functions.
Asset Has Sensitive Data	Indicates whether an asset stores sensitive data, such as PII.
Data Classification	Tracks the data classification of an asset, assigned through tagging. Organizations are encouraged to implement a tagging scheme to identify assets that contain sensitive data.
Data Compliance	Indicates whether an asset is marked for audits. This is set via tagging during integration onboarding.
Data Contents Count	Describes the relative size of an asset and its stored data. This is especially relevant for databases and storage buckets. Note that data size is not always directly proportional to asset value.
Sensitive Data Count	Indicates the amount of sensitive data stored on an asset. Assets storing more sensitive data should meet higher security standards and may be considered crown-jewel assets.
Distinct Findings Count: IoC/IoA	Distinct count of alert types found on an asset. For example, 1,000 “Unusual RDP” alerts and 20 “Suspected data exfiltration via SSH” alerts equal two alert types.
Encryption: Data at Rest	Assesses available encryption settings for an asset, including whether customer-managed or CSP-managed keys are used. This does not assess whether data was encrypted before being moved to the cloud.
Encryption: Data in Transit	Indicates whether data is encrypted in transit, preventing exposure at lower network layers.
Encryption: Secrets	Secrets such as passwords and access tokens should not be stored in plaintext. In general, use secret management services to securely store secrets, reference them dynamically with stricter authorization, and enable easier rotation.
Environment	Indicates the environment of an asset—development, staging, or production. Set via tagging during onboarding. Organizations should implement tagging schemes to help identify production-specific risks.
Factor Coverage	Indicates how many risk factors are applicable and assessed for a given asset type. Coverage may be limited by permissions granted to Longbow.
Functional Role	The classification of an asset and its role in an application. For example, an SQL database or a firewall.
Has Vuln	Indicates whether a known vulnerability exists on the asset.
IaC Drift	IaC drift occurs when assets originally created from an IaC template are manually modified and no longer match the template.
Immutability: Contents	Indicates whether the contents of an asset are modifiable or read-only. For example, whether objects in a storage bucket can be edited.
Immutability	Indicates whether the control plane settings of an object can be modified.
Internet-Facing	Internet-facing assets are publicly accessible and therefore exposed to the internet. Network reachability (e.g., via NACLs) is a key factor, though access and encryption controls may mitigate exposure. Factor levels vary based on the number of accessible ports and IP addresses.
Malware Count	The amount of malware on a compute asset. Malware count serves as a proxy for risk, though a single critical malware can be a high-priority issue.
Neglected	Neglected assets are those that have not been used or maintained for an extended period and may no longer be needed. Examples include outdated compute instances or unused access keys.
Network Reachability	Indicates whether an asset is reachable from the internet or from internal subnets.
Orphaned	Orphaned assets lack essential relationships and may be forgotten or unnecessary. Examples include databases with no applications, load balancers with no targets, or snapshots of terminated instances.
Owner	Identifies the person or team responsible for the asset to ensure accountability. The creator may be used as a proxy.
Permissions Level	Assets with high permission levels can perform many actions across many resources. Examples include using decryption keys or deleting critical resources.
Restorability	Indicates whether an asset is restorable to a known good state. This may include features like versioning, snapshots, or backup protection.
Role Permissions Level	The risk level calculated for a particular role that a principal can assume.
Secrets Count	Indicates whether an asset stores secrets and the number of secrets stored.
Source Code Integrity	Indicates whether source code is signed. Signed code helps protect against injection attacks and can apply to assets such as Lambda functions.
Unpatched Packages Count	The number of packages on an asset that have available updates.
Visibility: Logging	Indicates whether logging is enabled on an asset. For example, whether AWS CloudTrail is enabled.
Visibility: Scanning	Indicates whether an asset is regularly scanned for compliance or vulnerabilities.
Visibility: Tagging	Indicates whether an asset is appropriately tagged per organizational standards.
Vulnerability Aggregate Severity	An aggregate score for vulnerability severity on an asset. Useful for assessing the risk of critical and low-severity vulnerabilities together.
Zero Days	Number of potential zero-day vulnerabilities on an asset.
Access Activity Level	Indicates how frequently an asset is used. Unused assets can increase the attack surface and consume resources unnecessarily.
Cost	The total cost of operating the asset in the cloud. Cost is a weak proxy for asset value.
Asset Members: Internet-Facing	The number of internet-facing assets within the asset. For example, exposed containers on an EC2 instance.
Asset Members: Role Permissions Level	The permissions granted to assets within the asset. For example, what role a container can assume on an EC2 instance.
Image Hierarchy	Describes the hierarchy of a container image, such as how many images have been created from it.
Asset Members: Network Radius	Indicates whether the asset can access other networked assets. For example, whether a container can reach containers on other EC2 hosts.
Visibility: SSM Agent	Indicates whether an SSM Agent is running on the asset.
CWE Count	Count of CWEs present on the asset.
Visibility: Agent	Indicates whether a monitoring or scanning agent is running on the asset.
Policy Permissions Level	The permissions available to the asset through attached policies. Helps identify overly permissive configurations.
Asset Members: Neglected	Number of neglected assets within the asset. For example, containers running longer than their expected lifespan.
CWE Maximum Severity	CWEs on an image can indicate risks beyond known CVEs. Longbow uses third-party integrations to identify CWEs and map them to runtime assets for comprehensive risk analysis.
Has Sensitive Data	Indicates whether an asset stores sensitive data, such as PII.
Compliance Scope: Veracode Policy	Indicates whether the asset complies with Veracode policy.