Magento Open Source Security Scan Tool setup

What the Magento Open Source Security Scan Tool does for your store and when to use it

Adobe's Security Scan Tool is a free service for Magento Open Source stores that checks a store for known security issues and reports the results in a risk report. A merchant or platform lead should turn it on when they run a self-hosted store and want recurring visibility into security problems before a PCI DSS assessment, a patch cycle or a suspected incident. The most useful time to start is before the next assessment is scheduled, so the team has several reporting cycles to review and act on. It is not a substitute for a security program, and it does not replace work on the store itself.

Before you plan around the tool, confirm its current details in Adobe's documentation. Registration steps, the scan frequency options available to your store, the report layout and the kinds of issues it covers can change between releases, and none of them should be assumed from older guides or community posts. Check which store versions and hosting models the tool supports, since your store's version (for example, a 2.4.x release line) and whether it runs on infrastructure you control both affect what you can register and how often you can scan. Write down the answers so the operations owner, the security reviewer and any partner working on the store all work from the same version of the facts.

Treat scan output as an input to your security program, not as a compliance result. A clean or improved report does not mean the store meets any PCI DSS requirement, and findings do not establish that cardholder data is protected. PCI DSS is assessed through a Report on Compliance or a Self-Assessment Questionnaire with an Attestation of Compliance, completed by a Qualified Security Assessor or the merchant against official templates. Scan results can support that evidence, but the assessor decides what it proves. Keep the scan history as part of your records of vulnerability management and patching, next to change tickets and remediation decisions.

Decide early who owns the report. Someone needs to receive it, triage each item, decide whether it is a real issue, and track fixes through the same change process used for patches and code releases. Name a single owner for the store's security findings, define how often that person reviews the report, and agree which issues are escalated to the development team and which are accepted with a documented reason. Without this, a recurring report becomes a stream of unread emails and the store gains no benefit from scanning.

The tool also sets expectations about the rest of your security work. It will not show whether custom modules, third-party extensions or payment integrations follow secure coding practices, and it does not monitor for malware or unauthorized changes to files. Ask your team and any implementation partner which parts of the store they will test separately, how they will confirm that patches are applied on time, and how the scan results will be combined with other inputs before the first assessment or incident review.

Scan cadence and setup choices to decide before you register

This table compares weekly and daily scan cadences for the Magento Open Source Security Scan Tool, along with the account and environment choices to settle first. Read each row as a question your operations team must answer before registration. The main takeaway is that a daily cadence only pays off if someone owns the triage every day.

Factor	Weekly scans	Daily scans
Cadences your store can select	Confirm with Adobe that your store can select weekly scans before you plan the triage schedule.	Confirm with Adobe that your store can select daily scans before you assume them in your operating model.
Change between scans	Each report batches a week of changes, such as extension installs, config edits and theme updates, into one review.	Each report covers roughly one day of change, so a finding is easier to link to the deployment that caused it.
Who triages the output	A named reviewer on the platform team works through one batch and hands security items to a backlog owner.	A rota or on-call cover is needed, since new findings arrive every day, including days the store trades.
Noise a team can absorb	Easier to clear a batch and record false positives in one planned session.	Repeated low-value findings can cause fatigue, so agree suppression rules before the first daily report.
When daily is worth the load	Suits stores with infrequent releases and a stable set of extensions and integrations.	Worth considering when releases are frequent, third-party code changes often, or a recent incident raised concern.
Adobe account owner	Same under either cadence: a named employee or role-based mailbox, with a documented handover plan.	Same under either cadence: avoid tying the account to one contractor who may leave before the first review.
Admin accounts used for registration	Same under either cadence: a dedicated admin account with the least access needed, and a record of who holds it.	Same under either cadence: confirm with Adobe which access level registration needs before you create the account.
Environments in scope	Decide whether production alone or production and staging are scanned, based on where live cardholder traffic runs.	Decide the same way, and document which environments are excluded and why, so reviewers know the report's boundary.

How Security Scan Tool findings fit with PCI DSS scanning and malware monitoring

Adobe's Security Scan Tool is one input to your security picture for a Magento Open Source store. It does not stand in for the PCI DSS assessment that your payment brands may require, and a clean scan does not establish that your store is PCI DSS compliant. Before you rely on any scan result for payment-related decisions, confirm with your acquirer or payment brand which validation path applies to your business and how your store fits into that scope.

PCI DSS is owned and maintained by the PCI Security Standards Council (PCI SSC). The standard applies to entities that store, process or transmit cardholder data or sensitive authentication data, and to entities whose systems could affect the security of that cardholder data environment. That includes merchants, processors, acquirers, issuers and service providers. The PCI SSC does not enforce compliance itself. The individual payment brands decide which entities must comply and validate, and they run any enforcement programs. Ask your acquirer which brands apply to your store and whether you are expected to validate.

Validation takes one of two documented forms. A Report on Compliance (ROC) is completed by a Qualified Security Assessor, and it is supported by an Attestation of Compliance (AOC). A Self-Assessment Questionnaire (SAQ) is completed by the entity itself and also ends with an AOC. Compliance certificates issued by vendors or scanning providers are not recognized as validation. Your acquirer will typically ask for the AOC, so the artifact to plan for is the AOC, not a certificate or a scan badge.

Within that assessment, the Security Scan Tool findings belong alongside two other activities. PCI DSS requires quarterly external vulnerability scanning by an approved scanning vendor (ASV) for in-scope systems, and the requirements cover internal scanning and related testing as well. Malware monitoring and file integrity checks address a separate question: whether the live storefront has been altered, for example by skimming code injected into checkout pages. Map each tool to the requirement it supports, record who reviews its output, and keep the evidence that shows how each finding was closed or accepted. Confirm the scanning frequency and vendor requirements with your assessor or acquirer, since these depend on your scope.

Practical steps follow from this. Inventory which hosts, databases, admin paths and payment integrations sit inside your cardholder data environment, then decide which of them the Security Scan Tool covers. Assign an owner to triage findings and a second owner to review any finding marked as a false positive, so that the decision is documented before your assessor asks. If your team and your assessor disagree on scope, resolve that before the assessment starts. Changes to scope after a scan cycle often force repeat evidence collection.

Register the store and run your first scan in six steps

This sequence takes a Magento Open Source store from an unregistered state to a documented baseline. Each step ends with a check that someone on your team can verify, so the first scan produces findings with named owners and a review date.

Confirm the Adobe account and named owner
Before anyone touches the store, confirm which Adobe account will hold the Security Scan Tool registration and who in your organization owns it. Ask finance or procurement which account already sits under your Magento Open Source relationship, and name one accountable person with a backup. The owner should be able to sign in to that account, see the store context and approve access changes. Done means the owner's name, role and account identifier are written at the top of the findings register and the owner has confirmed that sign-in works.
Confirm base URLs and environments to scan
List every storefront and admin base URL that belongs to the store, including each store view domain and any staging or pre-production environment your team wants covered. Check that each URL resolves to the expected installation, and tag each environment by whether it holds live customer or cardholder data, since that affects priority and access. Confirm with the platform team whether each address is reachable from the scanning service, and whether any host sits behind an IP allowlist or VPN. Done means you have a written list of URLs and environments, each with its data sensitivity and reachability status.
Register the store using Adobe's current steps
Follow the registration steps in Adobe's current documentation for the Security Scan Tool, and check the date on any saved copy of those steps before you use it. Create or select the account the tool will use for the admin user and API access, and apply least privilege: a dedicated user, only the roles the scan requires, no shared credentials, and a documented owner for that user. Record the account name and the access scope granted. Done means registration completes for each URL on your list and an access review confirms the tool user holds no permissions beyond those the documentation requires.
Choose a cadence and name a notification recipient
Choose weekly or daily scanning based on how many findings your team can review, assign and close in each cycle. Confirm in Adobe's documentation what each option covers and how notifications are delivered, then start with the cadence your triage capacity supports. Name at least one person to receive notifications, plus a backup, and confirm that the address they use is monitored during working hours. Done means the cadence, the notification recipient and the backup are recorded, and the recipient has confirmed they receive the notification the tool sends.
Run or wait for the first scan
Start the first scan manually if the tool offers that option, or wait for the first scheduled run if it does not, and confirm which path the documentation describes. Freeze configuration changes to the store during the run so the baseline reflects a known state. Record the start time, the environments covered and the report identifier or version shown by the tool. If a scan fails or covers fewer URLs than your list, log the gap with an owner and resolve it before you accept the baseline. Done means a completed report exists for every environment on your list, or each gap is logged with an owner and a date.
Record the baseline in a findings register
Transfer every finding from the first report into a findings register with columns for finding, environment, severity as the report states it, owner, status and target review date. Assign each row a named individual, and record a team alias only as a backup. Set review dates that match your triage cadence, and mark suspected false positives as pending review with the evidence needed to confirm them. Link the register to your PCI DSS scoping and malware monitoring records, because scan findings are one input alongside those controls. Done means the accountable owner has approved the register and the baseline date is recorded.

Reading the risk report and handling false positives without losing real findings

The point of reading a scan report is to decide, for every finding, whether it becomes a fix, a documented compensating decision or a closed false positive with evidence. Start by sorting each finding on two axes: exposure (is the affected path reachable from the internet, from logged-in customers, or only from the admin area behind your access controls) and data sensitivity (does it touch the payment flow, the admin account and role model, or customer personal data). Findings that sit on the checkout, payment callback or admin login path go to the top of the queue regardless of the severity label the tool assigns. Confirm the exact report fields, severity definitions and export options with Adobe, because the layout of the Security Scan Tool report is not something this page can assume.

Before you accept or dismiss any item, confirm it against the live store. Load the flagged URL, reproduce the request or inspect the configuration setting the finding names, and record what you saw, including the store version, the active theme and the module list at that moment. A finding about a missing header, for example, may depend on the web server or CDN layer in front of Magento rather than on Magento itself. Some items will reproduce cleanly and move straight to a fix. Others will not reproduce at all, and those are the ones that need a written decision rather than a silent close. Keep the evidence with the ticket so an auditor or a later engineer can see how the conclusion was reached.

Every finding then ends in one of three outcomes. A fix is scheduled with an owner and a verification step. A compensating decision is used when the fix is not practical now: the record should describe the risk, the control that reduces it, who approved the decision and when it must be revisited. A false-positive closure needs a written rationale that explains why the condition does not exist in your environment, with the evidence attached. A closure that is valid today can become wrong after a module, theme, extension or patch changes the code path, so each false positive needs a re-check after every release, security patch or significant third-party change. Put these re-checks on the same calendar as your patch cycle, and reopen any closure whose evidence no longer matches the store.

Where a compensating decision relates to a PCI DSS requirement, be precise about what it is. PCI DSS v4.x lets an entity meet a requirement through the defined approach or, for entities with robust security and risk management, the customized approach, which meets the stated objective in a different way. Whether a given decision qualifies is for your assessor and your payment brands to judge, so record the objective being met and the evidence rather than a conclusion about compliance. Ask your Qualified Security Assessor, if you have one, how they expect exceptions and closures to be documented, and confirm the expected format before the first assessment cycle.

Magento Open Source controls that scan findings usually point to

A scan finding is only useful when the team can trace it to a control it owns. The cards below cover the Magento Open Source settings, platform components and operating practices that findings most often relate to, and what closes each one. Use them to sort findings into configuration fixes, patching work and review evidence before anyone argues about severity.

Content Security Policy headers

Content Security Policy is a set of response headers that tells the browser which scripts, styles and other resources a page may load. Magento Open Source supports these headers from version 2.3.5, and from 2.4.7 the policy runs in restrict mode by default on storefront and admin payment pages. A finding here usually means a policy is missing, set to report only, or allows broad sources that a third-party script depends on. Check each page type that loads payment or checkout scripts, confirm the active mode in the store configuration, and close the finding with the policy definition and a browser test showing no unexpected blocked resources.

Varnish full-page cache

Adobe documents Varnish as the full-page cache accelerator for self-managed Magento Open Source installations. A finding about caching can mean Varnish is not enabled, is pointed at the wrong backend, or serves pages that should never be cached, such as account or cart pages. Confirm the cache mode in the admin, the Varnish configuration generated for your web server, and the Varnish version against the support matrix for your release. Evidence that closes the item is the configuration file, the version check and a test showing private pages return no cached content to anonymous visitors.

Patch cadence and supported releases

Adobe's upgrade guide recommends upgrading every patch cycle to stay secure and PCI compliant, and its release schedule says security patches ship at least annually for all supported lines. A finding about outdated components usually means the store is on a release line that is near or past its end of regular support, or on a patch level behind the current one. Record the installed version, compare it with Adobe's lifecycle dates, and set a written patch window with an owner. The closing evidence is the patch log, the change ticket and a current version report.

Admin access and two-factor settings

Administrator accounts control catalog, orders, payment settings and user roles, so they are a common target for scan findings. Findings in this area often involve shared admin logins, unused accounts with broad roles, default or weak credentials, or two-factor authentication that is not enforced for every administrator. Review the user list and role assignments, remove accounts that no longer have an owner, and confirm two-factor settings apply to all admin roles. Closing evidence is the account inventory, the role matrix and a dated record of the two-factor configuration.

Custom modules and third-party extensions

Magento Open Source is extended through modules, themes and language packages, and custom modules usually carry the store's business logic and integrations. A finding in this area may point to an extension that is abandoned, unpatched, compatible only with an older release, or installed without a recorded owner. Build an inventory of each module with its source, version and release line, then review code paths that handle payments, customer data and admin input. Evidence that closes the item is the inventory, the review notes and the upgrade or removal ticket for each affected component.

Why your Magento Open Source version decides which findings you can fix

The version of Magento Open Source you run sets the limit on what a scan finding can realistically lead to. Adobe gives each 2.4.x release three years of standard support from general availability. The documented end-of-regular-support dates are August 11, 2026 for 2.4.6, May 31, 2027 for 2.4.7, May 31, 2028 for 2.4.8 and May 31, 2029 for 2.4.9. Before you register a store with the Security Scan Tool, confirm which 2.4.x line your production store runs and find its end date in Adobe's lifecycle policy. A finding on a line that has passed that date changes the question from "how do we configure around this" to "what does our upgrade path look like."

Adobe states that it releases security patches at least annually for all supported release lines, and its upgrade guide recommends upgrading every patch cycle to stay secure and PCI compliant. Those two statements together mean a store that falls behind on patches will receive fewer fixes over time, even while it is still on a supported line. Your scan results should be read against your patch level, not only your minor version. Check the release versions page for the patch you are on, compare it with the latest released patch for your line, and record the gap. A finding that is already patched upstream usually needs a version change, not a tuning change.

Some findings will trace back to core code that only a newer release line or a current patch corrects. When a finding sits in an out-of-support line, the fix may require moving to a supported release, which means testing your custom modules, themes and third-party extensions against the new code. Adobe's upgrade guide names customizations, extension count, third-party integrations and coding practices as the main drivers of that effort. Ask your team to list which findings map to core files and which map to your own modules before you open a change request. This split decides whether the work is a patch window or a project with its own test cycle and budget.

Mage-OS is a community-owned distribution built on Magento Open Source, run by the Mage-OS Association. Its site describes it as upstream compatible with Magento 2 extensions and lists releases that port Adobe security patches. That may matter to a team that cannot move to a newer Adobe line on its planned schedule. Evaluate it as a separate decision, not as a drop-in replacement. Confirm which Adobe patches each Mage-OS release includes, how quickly ports appear after Adobe publishes them, who signs the release artifacts, and whether your extensions, PCI DSS evidence and support contracts accept a non-Adobe distribution. Document the answers before you rely on it for remediation.

What to confirm in Adobe's documentation and your own environment

Adobe's documentation, your legal team and your own test store settle the questions that decide whether the tool fits your store. Each card names who should answer and what to record before go-live, so scan results can be traced to a known configuration.

Registration eligibility by edition and region

Confirm which Magento Open Source versions, store types and regions can register with the Security Scan Tool. Adobe's documentation for the tool sets these limits, and they may differ from what your team has read about Adobe Commerce. Ask Adobe for the answer in writing, then record the supported version range, any excluded store types and the regions where account data is processed before you register the first store.

Scan cadence per account

Check which weekly and daily scan options each account can select, and whether the setting applies per store or per account. Cadence determines how often new findings reach your queue and how much review time your team needs each cycle. Record the cadence chosen, who is allowed to change it, and whether a change takes effect immediately or at the next scheduled run.

Production or staging targets

Confirm whether the tool scans the live storefront and admin URLs, a staging copy or both. Scanning production can send probe traffic to live checkout and admin pages, so your change calendar and monitoring team need advance notice. Record the target URLs, the approved scan window and whether a staging result counts as evidence for production controls.

Data sent out and where it is kept

Ask Adobe which data the scan collects, where reports and account details are stored, which subprocessors handle them and how long they are retained. Your legal and privacy team should compare the answer with your data processing terms, especially if reports include hostnames, admin paths or configuration details. Record the data categories, storage locations, retention period and the deletion process.

Coverage of custom modules and themes

Confirm whether the scan covers custom modules, third-party extensions and custom themes, or only the core codebase. Custom code usually carries most of a store's specific risk, so a clean core result does not describe it. Ask Adobe how findings in custom code are reported, then record which directories, packages and themes your own code review must cover in addition to the tool.

Mage-OS installation eligibility

Confirm whether the tool accepts a Mage-OS installation. Mage-OS is a community distribution built on Magento Open Source, run by the Mage-OS Association, and Adobe may not treat it the same way as its own releases. Test registration on a non-production Mage-OS store first. Record Adobe's written answer, the version you tested and the fallback scanning method if registration is refused.

Questions teams ask before running Security Scan Tool setup

Does Adobe's Security Scan Tool cost anything to set up?

The scan tool is described as free, so the tool license is not the main cost. The real cost is your team's effort after the first scan: triaging findings, deciding which ones are false positives, fixing configuration and extension issues, and retesting. This effort recurs with every scan cycle, whether you scan weekly or daily, because each new finding needs an owner and a documented decision.

What moves the internal effort up or down:

the number of extensions and custom modules in the codebase
how many environments you scan
the size of the backlog from the first report
the change windows available for fixes

If you hire a partner, ask the quote to separate setup, triage, remediation and retest, and to state which items are one-time and which recur. Confirm the tool's current terms directly with Adobe before you budget.

How long does Security Scan Tool setup take for a Magento store?

The supplied material does not give a fixed duration for setup, so treat any timeline as something to agree in writing. Registration is rarely what sets the schedule. The duration depends on what happens after the first report.

Main drivers:

access to the store admin, hosting or cloud accounts, and the code repository
the number of environments registered, such as production, staging and development
the triage backlog, which can be large on an older store with many extensions
how quickly fixes pass your change process and reach production
how many retest cycles the findings require

Ask any provider for a schedule tied to these items, with each dependency on your side named and assigned to an owner.

What does the team need to provide before a scan setup starts?

The work depends more on decisions and access than on tooling. Name one owner who can approve scope, accept or reject findings and move fixes through your release process. That person should be able to answer questions about the storefront, payment and shipping integrations, and any custom code.

What to have ready:

a named owner with authority over changes
admin access to the store and a path to the codebase for review and fixes
hosting or cloud access for each environment in scope
agreed change windows, including a route for urgent patches
a findings register that records each finding, its owner, the decision taken, the fix and the retest date

Without a register, findings tend to be lost between the scan report and the next release.

Can an internal team set up Security Scan Tool without a partner?

Often yes, for registration and first-pass triage, as long as the team knows Magento Open Source well enough to judge whether a finding applies to its own configuration. Registration itself is a self-service step, and the tool's output is designed to be read by store operators.

The harder parts are judging findings in custom modules, deciding which systems fall within payment card scope, and finding enough engineering time to fix and retest. Teams that lack Magento development skills or that have a heavy extension footprint often find triage slow. An internal team can still run the process alone if it has a named owner, a register, protected time for fixes and someone who can explain the store's architecture to an assessor.

Does a Security Scan Tool result count as PCI DSS compliance?

No. A Security Scan Tool report is useful input to your security work, but it does not validate PCI DSS compliance. Validation is documented on official PCI SSC templates: a Report on Compliance completed by a Qualified Security Assessor, or a Self-Assessment Questionnaire, each supported by an Attestation of Compliance. The PCI Security Standards Council does not recognize compliance certificates as validation.

The payment brands decide which entities must validate and run any enforcement programs, so confirm your obligations with your acquirer or payment processor. Your scan records can support the evidence your assessor reviews, but the assessment itself is performed by an independent party. DeployOpen prepares systems, controls and evidence for assessments but does not issue reports, attestations or certifications.

When should a Magento merchant bring in an outside partner for scanning?

Bring in a partner when the work outgrows your team's capacity or expertise. Three triggers come up most often.

Typical triggers:

a large extension footprint or many custom modules that need code-level review
PCI DSS scope questions, such as which systems, integrations and staff access fall within the cardholder data environment
a backlog of findings that grows faster than the team can triage, fix and retest

DeployOpen can plan the scan program, triage findings, implement and harden fixes, and retest under a written scope with agreed deliverables and timelines. Security testing and remediation are separate deliverables, so define each one in the scope. Ask any partner to show how they will keep the register current after the engagement ends.

What does a Security Scan Tool finding need before someone acts on it?

Each finding needs an owner, a decision and a record before anyone changes code or configuration. Without these, the same issue reappears in the next scan and no one can show what was done.

Minimum record for each finding:

the affected environment, store view and component
a severity assessment made against your actual configuration, not the generic description
an owner and a target change window
a decision: fix, accept with a documented reason, or mark as a false positive with the evidence
the fix reference and the date it was verified by retest

Keep these entries in the findings register so that the scan history, the decisions and the verification can be reviewed together by your team or an assessor.

How DeployOpen scopes, delivers and supports Security Scan Tool setup

DeployOpen plans and configures Adobe's free Security Scan Tool for a Magento Open Source store running in infrastructure you control. We agree the scope in writing first, then set up registration, scan cadence and report review, and hand the results process to your team. Ongoing support is available as a retainer.

How we scope

The written scope names the store instances, domains and admin access paths the scan registration will cover.
We confirm which scan cadence, weekly or daily, fits your change rate and who receives each risk report.
Scope records how findings will be triaged, including who decides on false positives and how those decisions are logged.

How we build

We register the store with the Security Scan Tool and verify that the scan can reach the instance as intended.
We map each reported finding to the store's code, configuration and hosting layer so owners know where to act.
We check the Security Scan Tool output against your PCI DSS scoping and malware monitoring, noting where each tool covers different risks.

How we hand over

You receive a runbook covering registration details, scan schedule, report reading and the false positive review process.
We document each triage decision with the reason, reviewer and date so later reports can be compared against it.
Handover includes a walkthrough with the staff who will read reports and the owners who will fix findings.

How we support

Ongoing support is available as a retainer, covering periodic review of reports and changes to scan settings.
Re-review follows major Magento Open Source patch or release changes, since the scan's findings depend on the code and versions you run.
Any change to scope, cadence or triage ownership is agreed in writing before it takes effect.