The Briefing: Frequently Asked Questions

We use build and deployment context from CI/CD (branch names, tags, pipeline metadata, and deployment targets) plus per-project rules to understand where artifacts live. That lets dashboards, policies, SBOMs, and alerts become environment-aware — so you can see what’s in production right now versus what’s still in development.​

Moole generates SBOMs in standardized SPDX and CycloneDX JSON formats, including package names, versions, licenses, checksums, and metadata. SBOMs are attached to releases for audit trails, kept historically versioned, and include attribution so downstream teams can trust what’s inside.​

We suggest safe versions (favoring semver-compatible upgrades), bundle related changes to reduce churn, include clear release notes and compatibility hints, and respect your CI checks. Auto-merge on green is optional — you’re always in control of what lands in your codebase.​

Moole de-duplicates and ranks CVEs by severity and blast radius, then refines them with Reachability Analysis to highlight issues that are actually invoked. Incremental runs and production awareness mean alerts trigger only when real production exposure exists.​

Moole uses least-privilege read scopes by default and only writes if you enable Auto-PRs. Data handling is transparent — dependency metadata, results, and SBOMs — with purge controls, SSO/SAML, role-based access control (RBAC), and full audit logs.

Yes. Moole incrementally rescans changes and alerts only when new CVEs affect packages actually running in production, helping you stay focused on material impact.​

Yes. Moole can auto-create tickets and upgrade PRs in tools like Jira, Azure DevOps, Linear, and notify teams via Slack or Teams — meeting developers where they already work.​

Most teams connect their source control providers and start seeing meaningful insights in minutes — no heavy setup or agents required.​​