Sttor Documentation

Appearance

Overview ​

DevSecOps Bot by Sttor helps teams identify and govern open-source license risk across direct and transitive dependencies.

License Compliance is designed for day-to-day engineering workflows: ​

  • Detect licenses during Pull Request scans (shift-left)
  • Continuously monitor license drift with Branch scans
  • Produce auditable evidence for internal reviews and compliance reporting

What the platform typically reports: ​

  • Component name and version
  • Detected license(s)
  • Where it is introduced (PR / branch context)
  • A clear policy result (Allowed / Review / Issue / Block)

License Governance ​

License Governance lets you define how each license is handled for your tenant. You can configure policy outcomes such as:

  • Block at PR: prevent merge when a disallowed license is introduced
  • Mark as Issue: allow merge but create a trackable issue for follow-up
  • Allow: treat the license as acceptable
  • Review (recommended): flag as “needs legal/security review” without immediate blocking

Typical governance patterns: ​

  • Permissive licenses (MIT, Apache-2.0, BSD) → Allow
  • Copyleft licenses (GPL) → Review or Block (depends on distribution model)
  • Strong copyleft licenses (AGPL) → Often Block for proprietary SaaS unless explicitly approved
  • Custom / commercial licenses → Review
  1. Start with Issue/Review policies to understand your baseline.
  2. Promote high-risk licenses to Block at PR once you are confident.
  3. Use Branch scans to ensure long-lived branches don’t drift out of policy.

Overview ​

DevSecOps Bot by Sttor helps teams identify and govern open-source license risk across direct and transitive dependencies.

License Compliance is designed for day-to-day engineering workflows: ​

  • Detect licenses during Pull Request scans (shift-left)
  • Continuously monitor license drift with Branch scans
  • Produce auditable evidence for internal reviews and compliance reporting

What the platform typically reports: ​

  • Component name and version
  • Detected license(s)
  • Where it is introduced (PR / branch context)
  • A clear policy result (Allowed / Review / Issue / Block)

License Governance ​

License Governance lets you define how each license is handled for your tenant. You can configure policy outcomes such as:

  • Block at PR: prevent merge when a disallowed license is introduced
  • Mark as Issue: allow merge but create a trackable issue for follow-up
  • Allow: treat the license as acceptable
  • Review (recommended): flag as “needs legal/security review” without immediate blocking

Typical governance patterns: ​

  • Permissive licenses (MIT, Apache-2.0, BSD) → Allow
  • Copyleft licenses (GPL) → Review or Block (depends on distribution model)
  • Strong copyleft licenses (AGPL) → Often Block for proprietary SaaS unless explicitly approved
  • Custom / commercial licenses → Review
  1. Start with Issue/Review policies to understand your baseline.
  2. Promote high-risk licenses to Block at PR once you are confident.
  3. Use Branch scans to ensure long-lived branches don’t drift out of policy.

Apache License ​

Apache-2.0 is a widely used permissive license. Common approach:

  • Allow by default
  • Ensure attribution/NOTICE requirements are followed in distribution artifacts where applicable

What DevSecOps Bot by Sttor helps with: ​

  • Detecting Apache-2.0 across transitive dependencies
  • Tracking how/when it entered the codebase

MIT License ​

MIT is a permissive license commonly used in most ecosystems.

Common approach:

  • Allow by default
  • Maintain license text/attribution requirements where applicable

GPL ​

GPL (copyleft) can introduce obligations depending on how software is distributed and linked. Common approach:

  • Mark as Review or Block depending on your product model
  • Validate usage with legal/security

DevSecOps Bot by Sttor supports:

  • Detecting GPL components early in PRs
  • Enforcing governance policy (Issue/Block) consistently

AGPL ​

AGPL (strong copyleft) may impose obligations even for network use. Common approach:

  • Often Blocked for proprietary SaaS unless explicitly approved
  • If allowed, require documented approval + containment controls

BSD ​

BSD (2-Clause / 3-Clause) licenses are permissive.

Common approach: ​

  • Allow by default
  • Keep attribution requirements in mind

Restricted & custom licenses ​

Some packages may be: ​

  • Dual-licensed
  • Licensed under non-standard text
  • Commercial/proprietary terms

DevSecOps Bot by Sttor supports restricted/custom cases by: ​

  • Treating them as Review by default
  • Allowing you to map them into governance outcomes (Issue/Block/Allow)

Best practices ​

  • Keep a clear “Allowed / Review / Blocked” policy list per tenant.
  • Use PR blocking for the highest-risk licenses once teams are aligned.
  • Document an exception process (who can approve, for how long, and why).

Copyright © 2026 Sttor