stacs: Static Token And Credential Scanner
Static Token And Credential Scanner
STACS is a YARA powered static credential scanner which suports binary file formats, analysis of nested archives, composable rulesets and ignore lists, and SARIF reporting.
What does STACS support?
Currently, STACS supports recursive unpacking of tarballs, gzips, bzips, zips, and xz files. As STACS works on detected file types, rather than the filename, propriatary file formats based on these types are automatically supported (such as Docker images, Android APKs, and Java JAR fles).
Who should use STACS?
STACS is designed for use by any teams who release binary artifacts. STACS provides developers the ability to automatically check for accidental inclusion of static credentials and key material in their releases.
However, this doesn’t mean STACS can’t help with SaaS applications, enterprise software, or even source code!
As an example, STACS can be used to find static credentials in Docker images uploaded to public and private container registries. It can also be used to find credentials accidentally compiled in to executables, packages for mobile devices, and “enterprise archives” – such as those used by Java application servers.
How does it work?
STACS detects static credentials using “rule packs” provided to STACS when run. These rule packs define a set of YARA rules to run against files provided to STACS. When a match against a rule is found, a “finding” is generated. These findings represent potential credentials inside of a file, and are reported on for a developer to remediate or “ignore”.
If the finding is found to be a false positive – that is, a match on something other than a real credential – the developer can generate a set of “ignore lists” to ensure that these matches don’t appear in future reports.
The real power from STACS comes from the automatic detection and unpacking of nested archives, and composable ignore lists and rule packs.
In order to allow flexible and collaborative usage, STACS supports composable ignore lists. This allows for an ignore list to include other ignore lists which enable composition of a “tree of ignores” based on organisational guidelines. These ignore lists are especially useful in organisations where many of the same frameworks or products are used. If a team has already marked a finding as a false positive, other teams get the benefit of not having to triage the same finding.
In the same manner as ignore lists, rule packs are also composable. This enables an organisation to define a baseline set of rules for use by all teams, while still allowing teams to maintain rulesets specific to their products.
Copyright (c) 2021, Peter Adkins
All rights reserved.