Packaging Instructions for JavaScript and TypeScript

Compilation Guide

Supported JavaScript Libraries and Technologies

Veracode supports analyzing many client- and server-side JavaScript and TypeScript applications, including those that use HTML5 APIs, ECMAScript 2015, ECMAScript 2016, ECMAScript 2017, ECMAScript 2018, and JSX. Veracode also supports the following technologies:

Framework/Technology Supported Versions
Angular 0-1.x, 2.x, 4.x–8.x
AWS SDK for JavaScript 2.x.x
Backbone.js 1.3.3 and earlier
Bootstrap 1–4
Cheerio.js 0.2–0.20
Ember.js 1.x, 2.x
Express 0–4.17.1
jQuery All
Koa.js 0.x–2.3.0
Node.js 12.12.x and earlier
React.js 0.13–16.x.x, react-router versions 2–4
SAPUI5/OpenUI5 1.x
Underscore.js 1.8.3 and earlier
Vue.js 1-2.x, vue-router versions 1–3.x

Template Engines

Name Supported Versions
Angular templates All
Handlebars.js 1–4.x
Hogan.js 0–3.x
Mustache.js 0.6–2.2.x
Swig 1.x

Unsupported JavaScript Technologies

The Veracode Platform does not support the analysis of CoffeeScript or Dart applications.

Packaging Guidance for JavaScript and TypeScript

Veracode extracts client-side JavaScript from JSP files that are uploaded as part of a JAR, WAR, or EAR file, and creates a separate JavaScript module that is selectable for analysis.

Upload a ZIP file containing JavaScript source code, or files that contain JavaScript. Veracode only extracts JavaScript from files with the following extensions:
  • ASP
  • CSS
  • EHTML
  • ES
  • ES6
  • HANDLEBARS
  • HBS
  • HJS
  • HTM
  • HTML
  • JS
  • JSX
  • JSON
  • JSP
  • MAP
  • MUSTACHE
  • PHP
  • TS
  • TSX
  • VUE
  • XHTML
Note: If a packaged web application includes files that contain JavaScript and those included files have one of the file extensions in the previous list, Veracode extracts the JavaScript and scans it.

When analyzing Node.JS applications, if you want to analyze components within the node_modules folder, include it in the uploaded source. Files within the node_modules folder appear as selectable modules only if they are not listed as part of the dependencies or devDependencies sections of either the package.json or package-lock.json files.

Note: Excluding the node_modules folder from an upload may affect your SCA Results.

When you submit .NET applications that use TypeScript for analysis, package the TypeScript source files separately from the .NET application. For best results, do not precompile TypeScript applications into JavaScript. Submit only the TypeScript source files.

If your JavaScript build or packaging process produces source map files that include the original source, submit the MAP files with the other files in your application, which Veracode can use to provide greater accuracy when analyzing the application.

Veracode requires that you submit JavaScript as source code in a format readable by developers. Build steps that minify, obfuscate, bundle, or otherwise compress JavaScript significantly affect the quality of analysis results.

Packaging AWS Lambda Applications

Veracode requires you to submit applications built for AWS Lambda according to the AWS Lambda Deployment Package formats. For information, see https://docs.aws.amazon.com/ and search for AWS Lambda Deployment Package in Node.js.

Note: Veracode does not support the analysis of dependencies submitted as Lambda layers. To analyze Lambda components deployed in layers, submit them as standard deployment packages, or consider repackaging the function to include layer components as part of the lambda function package.

Identifying Lambda Function Handlers for JavaScript and TypeScript

In JavaScript, you pass either two or three parameters to Lambda function handlers depending on whether the functions are asynchronous. However, the JavaScript runtime allows functions to have multiple parameters.

To detect Lambda function handlers for JavaScript and TypeScript, Veracode accepts the YAML and YML configuration files included in the uploaded package from the serverless and AWS SAM frameworks. Veracode parses these configuration files to identify the function handlers defined in the uploaded artifact. Veracode does not use these configuration files to identify the configuration of layers or other settings.

If a deployment package does not contain a YAML configuration file, Veracode may not identify the deployment package as containing an Express or Koa application. Inn this case, Veracode applies these heuristics to identify the candidate source files in the deployment package:

  • If a directory called functions exists, every JavaScript file in every subdirectory below functions is a candidate file. Veracode does not consider files in any directories below one directory level to be candidate files.
  • Every JavaScript file in the top-level directory of the archive is a candidate source file.

After Veracode identifies a candidate file, the scan considers the exported functions attached to exports or module.exports as handler functions. Examples include:

  • exports.handler = async function(event, context) {
  • exports.handler = function(event, context, callback) {
  • exports.handler = async function(event, context, testval, testbar) {
  • module.exports.lambdaproxyentry = async event => {

Developers often configure Express or Koa applications that run as Lambda functions to use those Lambda functions as proxies for the original Express or Koa code. In these cases, Veracode analyzes the artifact as an uploaded, standalone Express or Koa application.

Software Composition Analysis

If you have a Veracode Software Composition Analysis subscription, you can include third-party components in your static analysis submission to report on vulnerabilities in those components. To effectively scan third-party components, the submitted application must also meet the packaging requirements for SCA upload and scan.