Add Dockerfile auto-discovery when scanning is enabled

[dc-larsen]

Problem

Customers currently need to manually specify Dockerfile paths in their config:

- uses: SocketDev/socket-basics@1.0.25
  with:
    dockerfile_scanning_enabled: 'true'
    dockerfiles: 'Dockerfile,docker/Dockerfile.prod,services/api/Dockerfile'

This is tedious and error-prone, especially across multiple repos where Dockerfiles may be in different locations.

Solution

Auto-discover Dockerfiles when scanning is enabled but no explicit paths are configured.

Before: Customer must know and list every Dockerfile path
After: Just enable scanning, Socket Basics finds them automatically

- uses: SocketDev/socket-basics@1.0.25
  with:
    dockerfile_scanning_enabled: 'true'
    # That's it - Dockerfiles are found automatically

Implementation

Added _discover_dockerfiles() method to the Trivy connector that:

1. Walks the workspace directory tree using os.walk()
2. Matches files against common Dockerfile naming patterns
3. Excludes directories that typically contain third-party or test code
4. Returns relative paths for discovered Dockerfiles

Discovery Patterns

Pattern	Examples
Exact match	Dockerfile
Prefix match	Dockerfile.prod, Dockerfile.dev, Dockerfile.test
Extension match	app.dockerfile, backend.dockerfile

Excluded Directories

Directories are excluded case-insensitively to avoid false positives:

Category	Directories
Dependencies	node_modules, vendor
Version control	.git, .svn, .hg
Test directories	test, tests, testing, __tests__, spec, specs
Test fixtures	fixture, fixtures, testdata, test_data
Examples	example, examples, sample, samples
Mocks	mock, mocks
Build artifacts	dist, build, out, target
Virtual envs	venv, .venv, env, .env
Caches	.cache, .tox, .nox, .pytest_cache
Socket Basics fixtures	app_tests

Behavior

Scenario	Result
dockerfiles explicitly set	Uses explicit config (no change)
dockerfiles empty + scanning enabled	Auto-discovers Dockerfiles
dockerfiles empty + scanning disabled	Skips scanning (no change)
No Dockerfiles found	Logs message, skips scanning

Test Coverage

15 unit tests covering all discovery and exclusion scenarios:

Running Dockerfile auto-discovery tests...

  ✓ discovers_dockerfile_at_root
  ✓ discovers_dockerfile_in_subdirectory
  ✓ discovers_dockerfile_with_suffix
  ✓ discovers_dockerfile_extension
  ✓ excludes_node_modules
  ✓ excludes_vendor_directory
  ✓ excludes_test_directories
  ✓ excludes_fixture_directories
  ✓ excludes_example_directories
  ✓ excludes_build_directories
  ✓ excludes_app_tests_directory
  ✓ discovers_multiple_dockerfiles
  ✓ empty_workspace_returns_empty_list
  ✓ no_dockerfiles_returns_empty_list
  ✓ case_insensitive_exclusions

Results: 15 passed, 0 failed

Test Details

Test	What it validates
discovers_dockerfile_at_root	Finds Dockerfile in workspace root
discovers_dockerfile_in_subdirectory	Finds docker/Dockerfile nested paths
discovers_dockerfile_with_suffix	Finds Dockerfile.prod, Dockerfile.dev
discovers_dockerfile_extension	Finds app.dockerfile, backend.dockerfile
excludes_node_modules	Skips node_modules/**/Dockerfile
excludes_vendor_directory	Skips vendor/**/Dockerfile
excludes_test_directories	Skips test/, tests/, testing/, __tests__/
excludes_fixture_directories	Skips fixture/, fixtures/, testdata/
excludes_example_directories	Skips example/, examples/, sample/, samples/
excludes_build_directories	Skips dist/, build/, out/, target/
excludes_app_tests_directory	Skips Socket Basics test fixtures
discovers_multiple_dockerfiles	Finds 4 Dockerfiles across different locations
empty_workspace_returns_empty_list	Handles empty workspace gracefully
no_dockerfiles_returns_empty_list	Returns [] when no Dockerfiles exist
case_insensitive_exclusions	Node_Modules, VENDOR, Tests all excluded

Files Changed

• socket_basics/core/connector/trivy/trivy.py - Added _discover_dockerfiles() method and integration
• tests/test_dockerfile_discovery.py - Pytest test suite (for future use with Python 3.10+)
• tests/run_discovery_tests.py - Standalone test runner (works with any Python 3.x)

Example Log Output

INFO - Auto-discovered 3 Dockerfile(s): Dockerfile, docker/Dockerfile.prod, services/api/Dockerfile
INFO - Running Trivy Dockerfile scanning
INFO - Running: trivy config --format json --output /tmp/xxx.json /workspace/Dockerfile

🤖 Generated with Claude Code

[ahmadnassri]

should exclude dirs based on content of .gitignore

[dc-larsen]

Good point. Using .gitignore would make exclusions project-specific rather than hardcoded.

A few considerations:

1. Parsing complexity - .gitignore supports wildcards, negations (!keep.txt), directory-only patterns, and nested files. Would need a library like pathspec to handle it correctly.

2. Different intent - .gitignore defines what Git shouldn't track, not necessarily what shouldn't be scanned. A Dockerfile in an ignored test fixture could still have real security issues worth catching.

3. Missing/minimal .gitignore - Not all repos have one, so we'd still need a fallback list.

For this PR, the hardcoded list provides predictable baseline behavior. Could add .gitignore support as a follow-up with a flag like respect_gitignore: true for users who want it.

Open to discussing if you feel strongly this should block the PR.

[dc-larsen]

Smoke Test Results

Ran a live CI test to verify the Dockerfile scanning toggle behavior.

Test Repo: dc-larsen/socket-basics-smoke-test
Workflow Run: #21077917665

Test 1: Toggle OFF (no dockerfiles input)

Input: No dockerfiles parameter
Expected: Trivy connector not loaded, no Dockerfile scanning

Result: ✅ PASS

Starting security scanning with dynamic connectors...
Results saved to: /github/workspace/.socket.facts.json
Scan completed!
Components analyzed: 0
Total alerts: 0

Note: Trivy connector was NOT loaded at all. The Dockerfile in the repo was ignored.

---

Test 2: Toggle ON (dockerfiles: Dockerfile)

Input: dockerfiles: "Dockerfile"
Expected: Trivy connector loaded, Dockerfile scanned

Result: ✅ PASS

Successfully loaded connector: trivy
Running Trivy Dockerfile scanning
Running: trivy config --format json --output /tmp/tmptfc38bze.json Dockerfile
Components analyzed: 1
Total alerts: 2
Found 1 high/critical severity issues

The job shows as "failed" because it found a USER root security finding (expected behavior).

---

Conclusion

The toggle behavior works as designed:

• Toggle OFF: Even with a Dockerfile present, no scanning occurs
• Toggle ON: Trivy loads and scans the Dockerfile, reporting findings