W HI T E PA P E R

Veracode
Cryptography
Primer
September 18, 2019
 OVERVIEW
How does the Veracode Application Security
Platform protect customer data?
Customers share data Customers upload files to Veracode Static Analysis or Veracode Greenlight to conduct
static analysis. All data is encrypted in transit via HTTPS. If a file is stored to disk, it is
with Veracode, including encrypted using a unique key generated by a key management server. New data keys
files and credentials, are generated for each account, application, and scan. Files are decrypted on disk
to conduct static prior to static analysis and immediately deleted. Below are details about how each
product implements this design.
analysis (full application
or incremental) or
dynamic analysis. The How does Veracode Static Analysis protect application code?
Veracode Application Customers upload files to Veracode Static Analysis. As part of the upload process,
the files are encrypted and stored in a file store. Decryption for the purpose of
Security Platform and analysis is performed by the scanning process ephemerally on disk.
all Veracode’s products
A unique data key is generated for every scan and encrypted by a master key stored
are designed to protect in a key management server (KMS). The key management server is hosted on a FIPS
customer data at rest and compliant hardened security appliance.
in transit. This document Data keys are stored in a secure data store. The encrypted data key is passed from
provides technical details the Veracode platform to the analysis engines when necessary, and the analysis
of Veracode’s approach. engines contact the key server to decrypt the data key so that customer binaries can
be decrypted. Keys and configurations are backed up daily to a password-protected
file, and the password is stored in a password safe.

Backup files are encrypted before being transported off-site for storage. Backups
of customer binaries do not leave the primary data center facility. Only customer
metadata is backed up off-site. In the event of a data center disaster, any pending
scans will require that their data be re-uploaded to the failover data center.

How does Veracode Dynamic Analysis protect customer data?

Customers may provide sensitive data, including application credentials, crawl
scripts and login scripts, as part of the configuration of a dynamic scan. Sensitive
files, including crawl and login scripts, are encrypted with a customer-specific key
and stored in encrypted database records, that are in turn stored in a database with
encrypted data-at-rest. Scanner logs are encrypted both with client-side encryption
and data-at-rest encryption, and stored in restricted access cloud storage (S3) with
keys managed by the KMS.

Veracode uses the Internal Scan Management (ISM) feature to allow dynamic
analysis scans to access internal customer networks by establishing a secure tunnel.
A onetime-use cryptographic token is used to register the ISM endpoint with the
gateway, and obtain an HMAC key that is used to sign all API outgoing request from
the customer network. At tunnel establishment time, an ephemeral 2048-bit RSA key
is generated to authenticate the scanner to the ISM gateway, and bulk transfers of
tunnel data are encrypted with a symmetric cipher. To help diagnose network issues,
Dynamic Scan Engineers can register an individual RSA or elliptic curve public key
that can be used to open a diagnostic ISM tunnel. This operation requires explicit
customer consent.

2 WHITEPAPER VERACODE CRYPTOGRAPHY PRIMER

 Read and write files
PERSISTENCE ENCRYPTED FILE
using encryption
TIER REPO

Read and write files,

Store and delete keys Application Data
using encryption key
Create and request
KEY MANAGEMENT Request access
access to keys
SERVER to keys
APPLICATION TIER
Send job-related requests ENGINE +
and metadata when relevant HOST
Data Requests

WEB TIER
No storage-level data encryption
shared with client. HTTPS only.

HTTP Requests How does Veracode Greenlight protect

application code?
BROWSER
No storage-level data Customers upload small files representing small units of code (Java class files and
encryption shared with client.
.NET DLLs) from customer integrated development environments (IDEs) to Veracode
Greenlight for static analysis. Analysis occurs inside a secure Veracode Virtual Private
Cloud environment hosted by AWS.
FIGURE 1 Veracode Application Security
Once the file is uploaded, it is stored in an in-memory cache, from which it is pulled
Platform encryption architecture
by an assigned Greenlight EC2 instance for processing. The Greenlight EC2 instance
calls the AWS KMS to create a new “one time” key to encrypt the binary to the local
disk on the EC2 instance; the plaintext and encrypted keys are held in memory,
and only the encrypted binary is written to disk. During this process, files are never
decrypted to disk; decryption for the purpose of analysis is performed only in
memory by the scanning process.

The encrypted binary and encryption key are then passed to the Veracode Greenlight
static analysis engine on the secure Greenlight EC2 instance for processing. The
Veracode Greenlight engine generates customer results, which are encrypted
and stored on disk on the EC2 instance. The results are decrypted in memory and
returned in memory to the user; they are cached in memory for 24 hours. The key is
destroyed at the end of the session.

For additional security, each AWS instance is terminated weekly, and the KMS master
key is rotated each time a new version of the Veracode Greenlight infrastructure is
deployed, at minimum once a month (in practice, more than once a day on average).
AWS instances are considered transient and are not backed up.

Because of these various levels of encryption, access to the AWS instance does not
permit anyone to access sensitive customer data.

3 WHITEPAPER VERACODE CRYPTOGRAPHY PRIMER

 AWS ELASTICACHE (In Memory) Pull customer code files from queue
and encrypt with one time key
This layer holds customer data and results
files in memory in preparation for Greenlight
to work with them or for them to be sent back
to a customer. Data is held unencrypted in
memory and is never written to disk

Customer Code Files Analysis Results GREENLIGHT HOST

Performs analysis and generates results. May
encrypt and store both binaries and results on
VERACODE API GATEWAY the local host storage. Recycled after use.
This layer does no encryption related to file
storage. Aside from processing HTTPS requests,
all data passes through this layer unencrypted. Read and write files,
using encryption key
Creates and
destroys keys
HTTPS Request Analysis Results

HOST FILE
INTEGRATED DEVELOPMENT STORE
ENVIRONMENT (IDE)
The IDE has no knowledge of storage-level AWS KEY
data encryption. MANAGEMENT SERVER

FIGURE 2 Veracode Greenlight Veracode offers two ways to perform Software Composition Analysis: a binary upload
encryption architecture scan and an agent-based scan.

How does Veracode SCA protect application

code?
Veracode offers two ways to perform Software Composition Analysis: a binary upload
scan and an agent-based scan.

Binary Upload SCA Scan

The binary upload scan currently leverages the same workflow as Veracode Static
Analysis. File upload and encryption are also handled by Veracode Static Analysis, as
described in Static Analysis section.

Customers upload their files to the Veracode Platform for Static Analysis, and if they
have purchased Software Composition Analysis then the uploaded binary file will be
analyzed by the Software Composition Analysis scanner in parallel with the Static
Analysis scan. The binary files that are encrypted during the Static Analysis process
are uploaded to server side encrypted (SSE) S3 bucket in AWS through an HTTPS
connection. During the analysis, the Software Composition Analysis (SCA) scanner
uses the same unique application encryption key used by Static Analysis to execute
the scan process. The encryption key is passed to the Software Composition Analysis
scanner from the Veracode platform through a HTTPS connection when the Software
Composition Analysis scan starts. The Software Composition Analysis scanner uses
this encryption key to decrypt binaries in memory during the analysis process.

After the analysis has finished, the binaries will be deleted from the SSE S3 bucket
based on Veracode’s retention policy.

The Software Composition Analysis scan results are stored in Veracode’s database and
there is no customer data written to the hard disk during or after the scan process.

After the analysis has finished, the Software Composition Analysis scan results are
stored in Veracode’s database and there is no customer data written to the hard disk
during or after the scan process.

4 WHITEPAPER VERACODE CRYPTOGRAPHY PRIMER

 PERSISTENCE ENCRYPTED FILE
TIER REPO

Store and delete keys Application Data

Create and request
KEY MANAGEMENT Request access
access to keys
SERVER to keys
APPLICATION TIER
Send job-related requests SCA
and metadata when relevant SCANNER
Data Requests

WEB TIER
No storage-level data encryption
shared with client. HTTPS only.

HTTP Requests
Agent-Based Repository SCA Scan
BROWSER
No storage-level data How Agent-based repository scans collect and use data
encryption shared with client.
Agent-based repository scans do not send any application code to the Veracode
platform. Scans are conducted entirely on your local workstation (or CI/CD build
server) and collect Evidence of the open-source libraries used by your repositories.

FIGURE 1 Veracode SCA encryption Examples of evidence include library coordinates for several supported package
architecture managers such as Maven/Gradle or NPM (e.g. a Maven groupId/artifactId/version
tuple), or SHA-256 hashes for file-based libraries such as a Java JAR file.

For example, the Apache commons-lang3 3.4 library might be

represented as evidence by the package manager coordinatesorg.apache.
commons:commons-lang3:3.4 or a JAR file with the SHA-256 hash:
734c8356420cc8e30c795d64fd1fcd5d44ea9d90342a2cc3262c5158fbc6d98b.

Once evidence is gathered (the collection methods vary based on the language types
and package managers detected in your repository), it is sent to the platform for
matching. In this step, we match the evidence (coordinates, hashes) in our open-
source library registry. Libraries may be associated to one or more vulnerabilities
which are reported back to the agent.

Some vulnerabilities have known vulnerable methods, or invocations that are known
to trigger vulnerable code paths. If these are found during the matching step, the
agent runs a call graph analysis on your code to determine if any vulnerable methods
are executed; if they are, the call chains from your app code to the vulnerable
methods are captured.

How Veracode stores data from Agent-based repository scans

By default, scan evidence and (if applicable) vulnerable method call chains are
saved in the Veracode platform database so that they may later be viewed on the
website in the form of various reports (libraries, licenses, vulnerabilities reports). In
addition, your scan may trigger Rules which may be configured to create Issues in our
database for tracking (such as a high-severity vulnerability, or GPL license in use).

5 WHITEPAPER VERACODE CRYPTOGRAPHY PRIMER

 How long is data from Agent-based repository scans stored?
Evidence from your repository scans is retained and may be browsed on the
Veracode SCA web site for 18 months.

How does Veracode Agent-based scanning protect your data?

Data transmitted from the agent to the platform is secured using TLS1.2 encryption.
The Agent-based scanning Veracode platform database is a private AWS RDS
Database instance in our private VPC. The Database server is encrypted at rest via
KMS. Access to platform data from the application layer is secured using industry-
standard Authentication and Authorization frameworks.

How long does Veracode store customer data?

For Static and SCA services customer binary files are automatically deleted from the
file share within 60 days from the result publish date of being uploaded, or in less
time as requested by the customer. Greenlight binary files are immediately deleted
following the completion of the scan. Static, SCA, Greenlight, and Dynamic scan
results are retained for the duration of the contract, or for less time if requested.
Result files are deleted in a cryptographically secure way by deleting the files from
the file store and the data key from the data store, then destroying the appropriate
key via the Key Management System. In this way, even if the files were to be
recovered, they could not be decrypted as the key is irrevocably destroyed.

How are Veracode’s encryption keys managedt?

As protecting customer data is vital to accomplishing Veracode’s mission, all
customer data processed by Veracode systems in AWS (binaries, code, scan results,
etc.) are encrypted using a highly-controlled set of Customer Master Keys (CMKs) in
the AWS Key Management Service (KMS). All CMKs used to encrypt customer data
are held within a dedicated AWS account controlled by Veracode’s internal security
team. No other group within the organization has any level of access to this AWS
account.

Access to use each CMK is governed through strict, key-specific key policies enforced
by AWS KMS. In general terms, Veracode’s key policies deny everything except:

• Key administration by the internal security team

• Key usage by the security principals used by Veracode’s programmatic services

These practices adhere to the principles of least-privilege access, providing

safeguards against improper data exposure and ensuring that CMKs are only usable
by the software services that require them. The use of CMKs also ensures that even
security principals with access to call encrypt/decrypt operations never have access
to the key material, which never leaves the AWS KMS FIPS compliant hardware
security modules unencrypted1.

6 1
https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html WHITEPAPER VERACODE CRYPTOGRAPHY PRIMER
 How does Veracode protect data in transit?
All communications from a user-agent (web browser, IDE plug-in, customer written
API script) to Veracode are protected by TLS version 1.1 / 1.2 using a sufficiently
strong cipher suite.

Veracode supports the following ciphers:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

TLS_RSA_WITH_AES_256_GCM_SHA384

TLS_RSA_WITH_AES_256_CBC_SHA256

TLS_RSA_WITH_AES_256_CBC_SHA

TLS_RSA_WITH_AES_128_GCM_SHA256

TLS_RSA_WITH_AES_128_CBC_SHA256

Veracode generates a private key using a pristine, non-networked host, and it is

physically protected during its lifespan. The generated certificate-signing request
is sent to the Certificate Signing Authority, and the signed certificate returned and
stored in a secure location.

7 WHITEPAPER VERACODE CRYPTOGRAPHY PRIMER

What encryption technologies are used to protect customer data
in transit and at rest?
The following encryption technologies are used by Veracode to protect customer accounts and data.

SECRET ALGORITHM GENERATION STORAGE LIFESPAN/ ACCESSIBLE BY

MATERIAL ROTATION POLICY

Platform User bcrypt Passwords are hashed Password hashes User passwords have • Application Tier
Password Hash using bcrypt with a and salts are stored an enforced lifespan • Persistence Tier
work factor of 13. PRNG encrypted in the of 90 days.
(Java SecureRandom) database with AES-128.
used to generate the
bcrypt salt.

Digital AES-128 Initialization routine The wallet key is stored Persistent key Persistence Tier
Wallet Key is performed that encrypted in a PKCS
generates an installation #12 file. A DBA must
specific key. provide a passphrase
upon database startup
to decrypt the master
key, which in turn
decrypts each table key.

Application AES-256 KeyGenerator utilizing Application keys are Persists for the • KMS
Key SecureRandom. stored in the KMS. lifespan of the • Persistence Tier
application.

Scan Key AES-256 KeyGenerator using Scan keys are stored Persists until the • KMS
SecureRandom method. in the KMS. scan is deleted by • Analysis Engines
the customer or the
binaries are purged
at the end of the
retention period.

Account Key AES-256 KeyGenerator utilizing Account keys are Persists for the • KMS
SecureRandom method. stored in the KMS. lifespan of the • Application Tier
account.

Backup Key AES-128 Backup Encryption Stored by Managed Persists for the System
Key generated and Backup Service Central lifespan of the Administrator
managed by Veracode control on a local Managed Backup and DBA
System Administrator. administration server. Service services (Veracode).
Managed Backup contract.
services does not
have access to
Backup Encryption.

Veracode’s application security business is a leader in helping organizations secure the software that powers
their world. Veracode’s SaaS platform and integrated solutions help security teams and software developers
find and fix security-related defects at all points in the software development lifecycle, before they can be
exploited by hackers. Our complete set of offerings help customers reduce the risk of data breaches,
increase the speed of secure software delivery, meet compliance requirements, and cost effectively secure
their software assets — whether that’s software they make, buy or sell. Veracode serves over a thousand
LEARN MORE AT customers across a wide range of industries, including nearly one-third of the Fortune 100, three of the top
WWW.VERACODE.COM, four U.S. commercial banks, and more than 20 of the Forbes 100 Most Valuable Brands.
ON THE VERACODE BLOG,
8
AND ON TWITTER. WHITEPAPER VERACODE CRYPTOGRAPHY PRIMER
Veracode is a registered trademark of Veracode, Inc.