Run the universal local audit
Open Security inside a project and choose Run audit. DevDock scans every registered folder, including folders with no recognized language or framework. The baseline scan is read-only, runs on the computer, and does not upload source code or depend on an online advisory service.
The report groups findings by critical, high, medium, and low severity, shows how many files and folders were covered, and records whether the bounded scan reached a limit. Start with critical and high findings, but read the rule, evidence, and remediation before changing a file.
- Confirm that every expected project folder is registered and available.
- Stop the scan if it is no longer relevant; a cancelled or limited scan is marked as truncated.
- Run again after remediation to verify that the baseline finding is gone.
Know what the baseline checks
The audit looks for private-key material; recognizable AWS, GitHub, GitLab, Slack, and live Stripe credential formats; possible literal assignments to password, secret, API-key, access-token, and client-secret variables; and sensitive environment or credential files tracked by Git.
It also reports symbolic links that resolve outside the registered project, overly broad Unix permissions on sensitive files, and dependency manifests without a recognized lockfile. These checks are language-independent and focus on common local exposure and reproducibility problems.
- Critical findings include private-key material and recognizable provider credentials.
- High findings include tracked sensitive files and likely hardcoded secret assignments.
- Medium findings include escaping symbolic links and unsafe sensitive-file permissions on Unix.
- Low findings include missing dependency lockfiles.
Understand the privacy boundary
A finding includes the rule identifier, severity, category, registered folder, relative path, relevant line when available, explanation, and a suggested fix. Matched secret values are intentionally never returned in the report or shown as evidence.
Generated output and common dependency directories are skipped. Binary, unreadable, oversized, or otherwise unsupported items are counted as skipped rather than silently treated as safe. The scan does not move, edit, revoke, rotate, or upload anything.
- Do not copy a suspected credential into an issue or support message.
- Open the referenced file locally and inspect only the minimum context needed.
- Treat skipped and unavailable content as outside the completed audit scope.
Read the audit limits correctly
The baseline scan is intentionally bounded so it cannot become an uncontrolled repository crawl. A run stops after 25,000 inspected files, 500 findings, 48 directory levels, or 30 seconds. Individual files larger than 1 MB are not read for secret patterns.
DevDock skips common generated and dependency directories such as .git, node_modules, vendor, target, dist, build, .next, virtual environments, Pods, DerivedData, Gradle output, coverage, and similar caches. A clear result means no baseline finding was detected inside the completed scope—not that the application is vulnerability-free.
- Check the truncated indicator before relying on coverage.
- Resolve large batches of findings, then scan again if the finding limit was reached.
- Audit generated artifacts separately when they are part of the shipped product.
Respond to secret findings
If a real provider token or private key appears in source, assume exposure extends beyond the current file. Revoke or rotate it first, replace the application configuration with a secure reference, remove the value from the working tree, and then address repository history according to the team's incident procedure.
For a possible generic assignment, verify whether the value is real, test data, or a false positive without posting it elsewhere. For a tracked .env or credential file, removing the file from the latest commit is not enough when a real secret has already entered shared history.
- Revoke or rotate before spending time on cosmetic cleanup.
- Search history and release artifacts using an approved internal process.
- Add a safe example or template file without real values.
- Re-run the audit and the relevant provider or repository checks.
Fix filesystem and dependency findings
An escaping symbolic link is not automatically malicious, but it expands what tools may reach when they traverse the project. Remove it or verify that every relevant tool treats the target as untrusted. On Unix, restrict sensitive files that grant access to group or other users, commonly with owner-only permissions.
A missing lockfile weakens reproducibility and reviewability. Generate the lockfile with the package manager chosen by the project, review it, and commit it when that ecosystem expects application dependencies to be locked. Do not add several competing lockfiles merely to silence the check.
- Confirm the actual symlink target before changing it.
- Use the project's ownership and permission policy, not a blanket recursive chmod.
- Choose one package manager and keep its lockfile beside the manifest.
Run dependency advisory scanners
The universal baseline scan does not query vulnerability databases. When DevDock detects npm, pnpm, Yarn, or Composer audit tasks, it lists those package-manager scanners beside the local report so you can run current ecosystem checks through the normal command pipeline.
Advisory scanners may use the network and inherit the behavior of the package manager they invoke. Review their command, working directory, lockfile, registry configuration, and output. A clean package audit does not replace source review, application testing, infrastructure hardening, or a professional security assessment.
- Run the scanner for each independently managed dependency root.
- Review severity, affected version range, exploitability, and available remediation.
- Avoid automatic major-version upgrades without application testing.
- Record accepted risk and compensating controls in the project's normal security process.