best: Copilot settings to reduce unsafe suggestions

Short answer / recommendation
Use GitHub Copilot for in-editor automated refactors but enforce strict guardrails: supply a banned-API list and a security-first system prompt for every refactor, run language-specific security linters (ESLint + eslint-plugin-security for JS/TS, Bandit for Python), run Semgrep and CodeQL in CI, and block PR merges unless tests + static-analysis pass.

Why this works
Copilot accelerates edits but can suggest deprecated or insecure patterns if the refactor prompt is ambiguous. The safest approach is a blend of: (A) deterministic prompt constraints that explicitly forbid insecure/deprecated APIs, (B) automated static checks that catch regressions, and (C) gatekeeping in CI/PR.

Concrete Copilot prompt & policy patterns (use as templates)
- Pre-refactor system instruction (prepend to every refactor): "Refactor the target functions per constraints below. DO NOT introduce deprecated or insecure APIs. If the codebase uses a banned API, keep existing behavior but flag TODO comments and do not replace it with a deprecated call. List any changes to third-party dependencies."
- Banned APIs list (inject into prompt): a short JSON or bullet list, e.g. "bannedAPIs: ['eval', 'Function', 'crypto.createCipher' (use crypto.subtle), 'oldDatabaseClient.query()']". Keep this list in repo (security/forbidden_apis.yml) and load it into the prompt generator.
- Output requirements: "Return only the modified file content and a one-paragraph justification of security decisions. Add unit tests or update existing tests if behavior changes. Add TODO comments for any unsafe refactors you could not complete."
- Diff-check prompt: after generating, ask Copilot to produce a 3-line summary of security-relevant changes.

Prompt pattern example (single-line starter):
"Refactor to remove code smells while preserving behavior. Forbidden: . Prefer: . Add/modify tests. If unsure, do not refactor and explain why."

Lint and review tool integrations (practical list)
- Pre-commit: run linters locally with pre-commit hooks (pre-commit framework) to block unsafe commits.
- ESLint + eslint-plugin-security + TypeScript strict mode for JS/TS projects.
- Bandit + Safety for Python dependency checks.
- Semgrep for custom rules (implement rules for banned APIs and deprecation patterns)—fast and tunable.
- CodeQL in GitHub Actions for deeper flow analysis on PRs; configure to fail the job on critical findings.
- Dependabot/Snyk for dependency patching and to refuse merges with high-severity vuln alerts.
- CI policy: require tests, lint, semgrep, and CodeQL to succeed before merge; set branch protection rules and require at least one security reviewer.

Decision criteria (choose what to emphasize)
- Budget: commercial SAST (Snyk, paid CodeQL rules) buys coverage and fewer false positives. Semgrep + open-source tools are low-cost and flexible.
- Team size/workflow: small teams can start with pre-commit + CI Semgrep; large orgs should add branch protections and org-wide forbidden API lists.
- Skill level: junior-heavy teams need stricter automated blocking; senior-heavy teams can allow suggestions but require mandatory security review.

Best-for / Avoid-if
- Best for: teams doing automated, large-scale refactors that need repeatable safety checks; codebases with many legacy/deprecated APIs.
- Avoid if: you want pure exploratory refactors without CI gating—safety checks will slow iteration.

Practical checklist (implement in this order)
1) Create forbidden_apis.yml in repo and maintain it. 2) Add pre-refactor prompt templates to developer docs and editor snippets. 3) Add pre-commit hooks for linters. 4) Add Semgrep + CodeQL + tests to CI; fail the pipeline on critical issues. 5) Enable Dependabot/Snyk and set vulnerability policy. 6) Require PR reviews and protect main branch. 7) Monitor alerts and iterate on forbidden rules.

If you want, I can draft a ready-to-copy Copilot prompt template and a starter Semgrep rule for a specific language.

Compare GitHub Copilot and Cursor