Problem
The GraphQL repository tree query (GraphqlRepoTree) hardcodes 3 levels of nested Tree fragments. Any files beyond depth 3 (e.g. a/b/c/d/malware.bin) are invisible to both binary detection checks:
- OSPS-QA-05.01 (
checkTreeForBinaries) — executable binary detection
- OSPS-QA-05.02 (
checkTreeForUnreviewableBinaries) — unreviewable binary artifact detection
This means a repository could hide forbidden binary artifacts by placing them in a deeply nested directory structure, bypassing the scanner entirely.
Current behavior
The code already documents this limitation:
// TODO: The current GraphQL call stops after 3 levels of depth.
// Additional API calls will be required for recursion if another tree is found.
Expected behavior
The scanner should recursively fetch subtrees when a tree entry is found at the deepest queried level, making additional GraphQL API calls as needed.
Considerations
- A max-depth guard should be added to prevent excessive API calls on deeply nested repos (e.g.
node_modules)
- An API call budget or rate-limit awareness may be needed
- This affects both
checkTreeForBinaries and checkTreeForUnreviewableBinaries
Problem
The GraphQL repository tree query (
GraphqlRepoTree) hardcodes 3 levels of nestedTreefragments. Any files beyond depth 3 (e.g.a/b/c/d/malware.bin) are invisible to both binary detection checks:checkTreeForBinaries) — executable binary detectioncheckTreeForUnreviewableBinaries) — unreviewable binary artifact detectionThis means a repository could hide forbidden binary artifacts by placing them in a deeply nested directory structure, bypassing the scanner entirely.
Current behavior
The code already documents this limitation:
Expected behavior
The scanner should recursively fetch subtrees when a
treeentry is found at the deepest queried level, making additional GraphQL API calls as needed.Considerations
node_modules)checkTreeForBinariesandcheckTreeForUnreviewableBinaries