Security Policy &
Responsible Disclosure
scd is a security tool built by a security company. We take the security of our own software seriously and welcome responsible disclosure from the community.
Found a vulnerability in scd?
scd is a security tool — and like any software, it may contain vulnerabilities. We encourage security testing of this product and welcome responsible disclosure from the research community.
Please do not open a public GitHub issue for security vulnerabilities, and do not publish or share details of the vulnerability publicly until a fix has been released. Premature disclosure puts users at risk before they have any means to protect themselves.
Report privately to security@activemind.se. Include as much detail as possible: steps to reproduce, affected version, and potential impact. We aim to acknowledge reports within 2 business days and will keep you updated throughout the process.
Credit is given to researchers who report valid findings responsibly. If you would like to be acknowledged publicly, let us know in your report.
Scanning scd itself will trigger findings — that is by design
If you run scd, another SAST scanner, or any security analysis tool against the scd source repository, expect a significant number of findings — particularly in the rule definition files under rules/.
This is intentional and does not indicate real vulnerabilities in the product.
Why the rule files trigger findings
The rule files contain the exact patterns that scd is built to detect: SQL injection constructs, command injection sequences, hardcoded secret patterns, path traversal examples, insecure deserialization fragments, and more.
These patterns exist because the scanner needs something concrete to match against when it evaluates detection logic. The same applies to test fixtures and any sample code used during rule development.
A finding in a rules/ file means the detection logic is working as intended — not that the codebase contains an exploitable vulnerability.
What is and is not in scope
-
In scope
Vulnerabilities in application logic — files under
bin/andlib/, excludinglib/rules/ - In scope Authentication, session handling, or privilege issues in scd-server
- In scope Supply chain issues — malicious dependencies or build artefacts
-
Not in scope
Findings in
rules/— these are detection patterns, not application code -
Not in scope
Findings in
test/or fixture files — these are intentional false-positive test cases - Not in scope Issues requiring physical access to the machine running scd
scd is one layer of defence — not a guarantee
scd is a static analysis tool that helps development teams identify common security vulnerability patterns in source code. It is provided as a technical aid to support — not replace — professional security practices.
Not a penetration test
scd does not perform dynamic analysis, runtime monitoring, penetration testing, or threat modelling. No automated tool can detect all vulnerabilities in a codebase. Classes of vulnerabilities exist that scd does not and cannot detect. A clean scan result is not a security certification.
Findings depend on coverage
Results depend on rule coverage, the languages and file types supported, and whether a vulnerability matches a recognisable pattern. Novel or highly application-specific vulnerabilities may not be detected. scd is designed to catch common, well-understood patterns consistently.
No liability
Activemind Solutions AB and the contributors to this project accept no liability for security breaches, data loss, regulatory penalties, or any other damages arising from the use or non-use of this tool — including cases where a vulnerability present in a scanned codebase was not identified by scd.
Security is a shared responsibility
Effective application security requires multiple overlapping measures: secure design, code review, dependency management, penetration testing, monitoring, and incident response. scd makes one of those layers — routine code scanning — easier and more consistent. It is not a substitute for any of the others.