Use Case: Code Security
Exposed secrets in code and logs
A developer accidentally committed a production AWS access key to a private repository. ManySignal detected the AKIA prefix, validated the key is active, and opened a rotation ticket before the next commit.
The secret that was in git history for 3 years
GitHub's 2023 secret scanning report found over 10 million secrets exposed in public repositories in a single year. But public repositories are only part of the problem — private repository secrets are accessible to every engineer with read access to that repository, which in many organizations means hundreds of people. And git history is permanent: a secret committed and immediately "removed" via a new commit is still present in the git object database and in anyone's local clone.
Log-based secret exposure is less discussed but equally dangerous. Applications that log environment variables during startup, or log request headers during debugging, routinely emit API keys and connection strings to centralized log platforms accessible by the entire operations team.
rule: secret_exposure_code_logs
type: pattern_match + validation
sources:
- github_webhook_push
- gitlab_webhook_push
- splunk_log_stream
- datadog_log_stream
- cloudwatch_logs
trigger:
- condition: secret_pattern_match(content) == true
- patterns: gitleaks_ruleset (150+ types)
enrichments:
- secret_validation: aws_sts, github_api, stripe_api
- exposure_scope: public_vs_private_repo, log_access_groups
- git_history_depth: all_commits_containing_secret
- rotation_workflow: vault_policy, cloud_iam_rotation
mitre: T1552.001 (Credentials in Files)MITRE ATT&CK mapping
Exposed secrets FAQ
What types of secrets does ManySignal detect in code and logs?
AWS access keys (AKIA prefix), GitHub PATs (ghp_, gho_, github_pat_ prefixes), Google service account JSON keys, Stripe live and test keys (sk_live_, sk_test_), SendGrid and Twilio API keys, Slack tokens (xoxb-, xoxp-), Azure connection strings, database connection strings with passwords, private SSH and TLS keys, and generic high-entropy strings in credential-adjacent contexts. Coverage spans 150+ secret types.
How does ManySignal detect secrets in log files rather than just source code?
Log scanning is a separate detection stream that analyzes application log output piped to Splunk, Datadog, CloudWatch, or Elastic. Application logging of environment variables (especially during startup or errors), request/response logging that captures Authorization headers, and debug-mode logging that dumps secrets are all common sources. ManySignal's log scanner runs the same pattern library as the code scanner.
Does ManySignal verify whether a detected secret is still active?
For AWS IAM keys, GitHub PATs, Stripe keys, and several other providers, ManySignal performs a validation API call to check whether the secret is still active. Active secrets receive a higher risk score and trigger immediate rotation workflows. Expired or revoked secrets are still documented but receive lower priority.
Can ManySignal prevent secrets from being committed in the first place?
Via pre-commit hook integration with Gitleaks and GitGuardian, ManySignal can block commits containing detected secrets before they reach the repository. This requires installing the hook in developer environments or enforcing it via GitHub Actions on push. The detective capability (scanning existing commits and logs) is complementary, not a replacement.
Find and rotate exposed secrets before attackers exploit them
150+ secret type detection across code repositories and application logs, with active validation.