Add support for SECRET_TYPE_FILTER environment variable to filter secret scanning alerts

[Copilot]

This PR adds support for filtering secret scanning alerts by specific secret types using a new SECRET_TYPE_FILTER environment variable, as requested in the issue.

Changes Made

• Added SECRET_TYPE_FILTER environment variable support in main.py
• Updated all secret scanning functions to accept an optional secret_type_filter parameter:
  • get_repo_ss_alerts()
  • get_org_ss_alerts()
  • get_enterprise_ss_alerts()
• Enhanced URL construction to include the secret_type parameter when filtering is requested
• Updated documentation in README.md to describe the new environment variable

Usage

Set the SECRET_TYPE_FILTER environment variable with a comma-separated list of secret types:

export SECRET_TYPE_FILTER="password,api_key,oauth_token"

This will filter secret scanning alerts to only include the specified secret types, matching the GitHub API's secret_type parameter behavior.

Example

The implementation supports the exact filtering pattern mentioned in the issue:

SECRET_TYPE_FILTER="password,http_basic_authentication_header,http_bearer_authentication_header,mongodb_connection_string,mysql_connection_string,openssh_private_key,pgp_private_key,postgres_connection_string,rsa_private_key"

Backward Compatibility

• When SECRET_TYPE_FILTER is not set, the behavior remains unchanged (all secret types included)
• Existing functionality and API signatures are preserved
• No breaking changes to current usage patterns

Fixes #76.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[felickz]

Do not make this an input optional, just do it by default.

Instead of modifying the single query for secrets, this will require us to make two api calls.

The first query should remain as is, that will return all the default secret types (this excluedes the list the generic ones).

Then we need to make a second query with the applied filters (just hardcode this list as there is no better way).

Combine both results, there should not be duplicates CURRENTLY for this - there might be scenario in the future where the call without any filters actually does return the secret types for generics. Therefore create a combined (deduped list). If you can easilly detect duplicates, write a warning to the GitHub action output that says to notify the repo owners via an issue to report this duplicate behavior (this means we need to undo this change).

Thanks!

[Copilot]

Do not make this an input optional, just do it by default.

Instead of modifying the single query for secrets, this will require us to make two api calls.
...

I've redesigned the implementation per your feedback in commit 14c7226:

• Removed the optional SECRET_TYPE_FILTER environment variable
• Modified all secret scanning functions to always make two API calls by default:
  1. First call: Regular query without filters (returns default secret types)
  2. Second call: Query with hardcoded generic secret types list
• Combined results with deduplication logic
• Added GitHub Actions warning output when duplicates are detected

The hardcoded generic secret types list includes: password, http_basic_authentication_header, http_bearer_authentication_header, mongodb_connection_string, mysql_connection_string, openssh_private_key, pgp_private_key, postgres_connection_string, rsa_private_key

[felickz]

LGTM - on a repo level test (todo test org/ent)

before ... no CSV when a repo only contained "generic" secrets and 0 "default"

after -

A different repo with both Default + Generic secrets detected - lists are combined:

[felickz]

Future proofing this fix in case the generic secrets are eventually returned via the normal API response without any explicit filtering.