Consider splitting Security Product analyzers between build and scan functionality
Problem to solve
Our many analyzers currently do more than just analyze users' code. Due to the necessity of building projects and/or pulling in dependencies in many cases, we must run such commands as
yarn install or
mvn compile to ensure all dependencies and targets exist prior to running a security scan. This is largely an automatic task yet in many cases a user wants to disable the build step or specify a special build configuration, see examples:
Python project dependency check failed#6713 (closed)
Retire.js analyzer needs node_modules directory#9291 (closed)
There are certain workarounds that have been supported, such as Leveraging existing build jobs for SAST, DS and Using $SETUP_CMD to bypass package manager auto-detection , but they are distinct and we are not providing a uniform experience to handle this.
We should explore isolating the build stage of our analyzers and providing a common interface for skipping or customizing it.
- Build step is made more explicit - users can more easily opt-out or sub their own build-step
- Build and Scan steps are documented by design - this is currently implicit, which is confusing and non-intuitive
- Eliminate duplicate efforts across GL Stage groups - We are duplicating logic for auto-builds between devops:secure and devops:configure (auto devops) when we should not have crossed efforts. Builds are not necessarily a Secure responsibility
- (Potentially) Functionality remains hidden behind scanners - no change to primary APIs but substantial flexibility.
- Breaking change to existing interfaces
What does success look like, and how can we measure that?
- Users have an explicit understanding of how our scanners both build and scan projects
- Users can easily override the build stage for their framework/language using the same method across all scanners