On this page
Automation has an explicit boundary
Magebean uses automated verification only when the relevant state can be observed reliably by Magebean CLI or a supported integration. Automation can make verification repeatable; it cannot replace architecture knowledge, business context, organizational records, or professional judgment.
A catalog of Rules is not an equal number of automated checks. In the MVP, each Rule uses automated or human-required verification; hybrid Rules are not available.
Interpret verification outcomes accurately
| Outcome | What it means | What it does not mean |
|---|---|---|
| Automated pass | The observed condition met the check criteria. | The full requirement or system is certified secure. |
| Automated failure | The check observed a gap or unacceptable state. | Impact and remediation are known without review. |
| Human-required | Testing, review, evidence, or judgment is still required. | The rule failed or can be ignored. |
| Unavailable evidence | The assessment could not establish the expected outcome. | A pass, failure, or not-applicable decision. |
Applicability is a scoped decision
A rule is applicable when its expected outcome relates to the instance, component, feature, data flow, or process in scope. Mark a rule not applicable only when the relevant condition is genuinely absent.
Record who made the decision, the rationale, affected scope, date, and review trigger. “Not tested,” “no evidence,” and “not applicable” are different states.
Rule and profile coverage
Profile coverage describes how Magebean organizes and maps rules to a security objective. It does not imply that every source requirement is fully automated or that every possible Magento architecture is represented.
Coverage changes as standards, Magento versions, extensions, deployment models, and Magebean checks evolve. Each Assessment snapshots its Baseline configuration at creation. Later Baseline changes do not migrate into that Assessment, and Baseline version history is outside the MVP.
Company administration and authorization
Magebean uses one tenant type: Company. Roles are Company-defined rather than fixed operational personas. Role assignments may be Company-wide or scoped to selected Instances; Assessment-level access is outside the MVP.
Tenant isolation, scoped permissions, and self-approval prevention must be enforced by server-side authorization. Separation of duties is not only a user-interface convention: a requester or submitter cannot approve their own governed decision when independent approval is required.
Local checks, remote data, and sensitive evidence
Most CLI checks execute locally. Rules requiring Magebean advisory, package-status, or Adobe patch data call the documented API endpoint with endpoint-specific fields. Review the CLI data disclosure for current request schemas.
Treat Assessment Evidence as potentially sensitive. Store it privately and provide access through short-lived URLs. Minimize collected data, restrict access, remove secrets and unrelated personal information, define retention, and review files or logs before sharing them.
Agent tokens are Instance-scoped, hashed by the server, revocable, and rotatable. The raw token is shown only once and must not appear in source control, logs, Tickets, Reports, or support messages.
Features outside the MVP
Do not rely on Baseline version history, automatic Assessment migration, copied results between Assessments, cross-Assessment Finding deduplication, multiple Remediation Tickets for one Finding, complex multi-stage approvals, or email notifications.
The MVP does not provide Jira, Linear, or GitHub issue synchronization; AI remediation; security scoring; external benchmarking; direct large-video upload; SaaS-initiated remote CLI execution; generic GRC; incident-response management; or multi-tool ASPM orchestration.
Standards and compliance limitations
Use the current source standard and platform documentation as authoritative. Magebean profiles and mappings help operationalize expectations; they do not replace official requirement text.