Check dependency automation at the repository root for nested apps

[jplhomer]

WHY are these changes introduced?

Refs shop/issues-develop#24160.

MISSING_DEPENDENCY_SECURITY_AUTOMATION never passes or reports for an app below its Git repository root, such as apps/foo in a monorepo. Discovery rejects the app as "nested below a parent Git repository", so the check is always unresolved, even when the root has .github/dependabot.yml.

WHAT is this pull request doing?

Looks for Dependabot and Renovate configuration at the root of the nearest Git repository that holds the app, which is where those bots read it.

• Flat apps, and apps outside a repository, behave as before.
• When the repository root is inside a scan directory (for example --include-dir set to the root), only gathered paths are read, so --exclude and Git ignore rules still apply.
• Otherwise the allowlisted paths are read directly, contained by the repository root: symbolic links can't leave it, and the size limit and skipped-file reporting still apply.
• An app with its own .git keeps its own boundary, so a parent repository's configuration can't make it pass.
• Configuration only inside a nested app directory isn't read by the bots, so it's now reported as missing instead of unresolved.

Includes a @shopify/app patch changeset (.changeset/app-security-dependency-automation-repository-root.md).

How to manually test your changes?

mkdir -p /tmp/mono/.github && cd /tmp/mono && git init -q
printf 'version: 2\nupdates: []\n' > .github/dependabot.yml
# Put an app in apps/foo: a shopify.app.toml and a package.json with dependencies
shopify app security check --path apps/foo

In deterministic-findings.json, MISSING_DEPENDENCY_SECURITY_AUTOMATION is executed with no findings, and ../../.github/dependabot.yml is among its inspected files. Before this change it's unresolved. Delete the root dependabot.yml and the check reports a finding.

Checklist

• I've considered possible cross-platform impacts (Mac, Linux, Windows)
• I've considered possible documentation changes
• I've considered analytics changes to measure impact
• The change is user-facing — I've identified the correct bump type (patch for bug fixes · minor for new features · major for breaking changes) and added a changeset with pnpm changeset add

---

PR authored by Qlaw

[Copilot]

🟢 Approval recommended

The implementation safely addresses the reported nested-app behavior with comprehensive boundary and integration coverage.

0 open findings

What changed in this PR

Resolves dependency-automation detection for apps nested within Git repositories.

Changes:

• Resolves Dependabot/Renovate configuration from the nearest repository root.
• Preserves scan exclusions, bounded reads, symlink containment, and nested repository boundaries.
• Adds integration/discovery coverage and a patch changeset.

File	Description
dependency-automation.test.ts	Adds nested-app integration tests.
dependency-automation-discovery.test.ts	Tests repository boundaries and safe reads.
scanners/​types.ts	Updates discovery contract documentation.
scanners/​discover.ts	Implements repository-root configuration discovery.
Changeset	Documents the user-facing fix.

🧠 Review effort: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[jek]

Should we check dependency automation for every repository containing a gathered package manifest with dependencies?

   monorepo/
   ├── .git/
   ├── renovate.json
   ├── apps/foo/package.json
   └── vendor/tool/
       ├── .git/
       └── package.json

or

  app-repo/
  ├── .git/
  └── package.json

  web-repo/
  ├── .git/
  ├── dependabot config
  └── package.json

[jplhomer]

@jek Yeah, maybe a follow-up PR that groups package files by their nearest git root? Mainly addressing your second example. The first one looks like a submodule situation.