Setup CDS extractor esbuild JS bundle #203
Conversation
Changes the build process for the CDS extractor to produce `dist/cds-extractor.bundle.js` and `dist/cds-extractor.bundle.js.map` files instead of a pair of `.js` and `.js.map` files for every compiled `.ts` file. Allows for pre-build of the JavaScript code used to run the CDS extractor while committing the bare minimum number of files for the "distribution" of the build.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
Adds a GitHub Actions workflow for "CDS Extractor Distribution Bundle" in order to integrate the linting, unit testing, compiling, and bundling of CDS extractor TS code into a single NodeJS-compatible bundle.
…p-js into cds-extractor-dist
Removes shell-quote as a dependency of the CDS extractor and implements alternative approaches to sanitizing the data sources that had previously been sanitized via the `quote` function of the shell-quote library, which causes a code scanning alert when included in the all-in-one `cds-extractor.bundle.js` file.
There was a problem hiding this comment.
Pull Request Overview
This PR introduces a comprehensive build system overhaul for the CDS extractor, implementing an esbuild-based bundling process that simplifies deployment and improves security. The changes replace the previous TypeScript compilation approach with a single pre-built JavaScript bundle, eliminating runtime dependencies and command execution vulnerabilities.
- Migrated from TypeScript compilation to esbuild bundling with automated CI/CD validation
- Enhanced command validation with predefined secure patterns and absolute path verification
- Streamlined deployment scripts to use pre-built bundles instead of runtime compilation
Reviewed Changes
Copilot reviewed 20 out of 23 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| validate-bundle.js | New validation script for testing bundle integrity and execution |
| esbuild.config.mjs | ESBuild configuration for creating the bundled extractor |
| src/cds/compiler/command.ts | Enhanced command validation with secure pattern matching |
| src/utils.ts | Added path resolution and validation for source root arguments |
| index-files.sh/.cmd | Simplified to use pre-built bundles instead of runtime compilation |
| package.json | Updated build process and removed shell-quote dependency |
| .github/workflows/cds-extractor-dist-bundle.yml | New CI workflow for bundle validation |
Files not reviewed (1)
- extractors/cds/tools/package-lock.json: Language not supported
Applies suggestions from Copilot review of PR advanced-security#203 for the `advanced-security/codeql-sap-js` repo.
Standardizes the CDS extractor build configs to use a 'node20' as the JS runtime "target". Updates the CDS extractor's package.json file in order to specify required "engines" for `node` and `npm`. Minimizes the `tsconfig.json` config used by the CDS extractor in order to only specify configs required for linting and testing, given that the main build config is now specified in the `esbuild.config.mjs` file.
| /** | ||
| * Predefined secure CDS command patterns | ||
| */ | ||
| const ALLOWED_CDS_COMMANDS = { |
There was a problem hiding this comment.
I don't believe we actually need to implement an allow list for cds commands. Reviewing the code, I believe the command tested against this list is exclusively generated by the getBestCdsCommand. The command provided by that function is either already one of the items from this list, or it is a command created from a fixed path prefixed with the cache directory, in which case it is not checked against this list anyway.
Instead of an allow list, I think we should just generate the "validated commands" directly - e.g. an object with the executable and args properties.
There was a problem hiding this comment.
I made an attempt to rework the "validated commands" approach.
This pull request introduces significant improvements to the CDS extractor toolchain, focusing on bundling, validation, and command execution. The changes include adding a new esbuild-based bundling process, streamlining execution scripts, enhancing command validation, and updating dependencies. These updates aim to improve performance, simplify workflows, and enhance security.
Build and Workflow Improvements:
.github/workflows/cds-extractor-dist-bundle.yml: Added a GitHub Actions workflow to automate the validation, linting, testing, and bundling of the CDS extractor. This includes checks for bundle size, source map presence, and Node.js shebang.extractors/cds/tools/package.json: Migrated the build process to useesbuildfor bundling, added scripts for validating the bundle, and removed unnecessary dependencies such asshell-quote. [1] [2] [3]Codebase Simplification:
extractors/cds/tools/esbuild.config.mjs: Introduced anesbuildconfiguration for bundling the CDS extractor into a single file (cds-extractor.bundle.js) with source maps and Node.js shebang.extractors/cds/tools/.gitignore: Updated.gitignoreto include the bundled JS file in thedistdirectory.Command Validation Enhancements:
extractors/cds/tools/src/cds/compiler/command.ts: Added predefined secure CDS command patterns and implemented validation logic to ensure commands are either absolute paths or match allowed patterns. This reduces the risk of command injection and improves reliability. [1] [2] [3] [4] [5]Script Updates:
extractors/cds/tools/index-files.cmdandextractors/cds/tools/index-files.sh: Updated scripts to use the pre-builtcds-extractor.bundle.jsinstead of requiring TypeScript compilation and dependency installation at runtime. Simplified logic for checking and running the bundle. [1] [2]These changes collectively improve the efficiency, security, and maintainability of the CDS extractor toolchain.