Deepsec 语言感知式安全审查提示词：多语言仓库中纯 TypeScript 批次的过滤组装机制

应用安全漏洞扫描人工智能AI Agent【免费下载链接】deepsecDeepsec is a security harness for finding vulnerabilities in your codebase powered by coding agents项目地址https://gitcode.com/gh_mirrors/deeps/deepsec点击查看免费下载本指南以 prompt-samples/05-polyglot-typescript-batch-filters-other-techs.md 为线索深入讲解 Deepsec 如何在一个同时检测到 Next.js、React、Express、Django、Rails、Node 的多语言仓库中为纯 TypeScript 文件批次自动过滤掉无关框架的威胁提示、按需注入漏洞 Slug 审查备注最终组装出一份可直接投喂给编码 Agent 的完整安全审查提示词。读完本文你将掌握 Deepsec 提示词的三段式组装管线核心提示词 技术高亮 Agent 层封装、语言过滤与 Slug 过滤的底层原理以及如何通过UPDATE_PROMPT_SAMPLES1 pnpm test:unit重新生成这些确定性的提示词样例。场景是什么一份被过滤过的完整审查提示词prompt-samples/目录下的每个.md文件都是 Deepsec 在实际运行时真正发送给编码 Agent 的完整提示词的确定性快照snapshot。它们不是手写文档而是由 packages/processor/src/tests/prompt-samples.test.ts 通过生产代码路径自动生成并提交到仓库中的测试夹具fixture。场景 05 的头部注释完整交代了它的定位Scenario: 05-polyglot-typescript-batch-filters-other-techs Same polyglot repo as scenario 4, but the batch is pure TypeScript. Django and Rails highlights drop out; Next.js / React / Express remain. Detected tags : [nextjs,react,express,django,rails,node] Batch files : [apps/web/app/api/login/route.ts,apps/api/src/server.ts] Batch langs : [typescript] Batch slugs : [all-server-actions,js-express-route,xss] Generated by : packages/processor/src/__tests__/prompt-samples.test.ts Regenerate : UPDATE_PROMPT_SAMPLES1 pnpm test:unit一句话概括该场景仓库是六种技术栈混杂的多语言仓库但本轮扫描待审查的批次文件只有两个 TypeScript 文件。因此虽然项目整体被检测出django、rails标签它们的技术威胁提示Threat Highlights在本轮提示词中被语言过滤机制剔除只保留与 TypeScript/JavaScript 相关的 Next.js、React、Express 三份同时仅当批次中确实命中了all-server-actions、js-express-route、xss这三个漏洞 Slug 时对应的审查者备注才会被注入。这就是polyglot多语言 batch批次 filters过滤三个关键词的全部含义。提示词在 Deepsec 流水线中的位置在深入解析提示词内容之前先看它在整体架构中的位置。docs/architecture.md 描述了 Deepsec 的稳态流水线steady state: scan → process → revalidate → enrich → export/reportscanpackages/scanner用正则与启发式匹配器对文件打候选标记产出CandidateMatch漏洞 Slug、命中行号、匹配模式processpackages/processor把候选批次交给编码 Agent 做深度审查——这正是本文提示词的用武之地revalidate让 Agent 对已产生的 finding 二次判定enrich / export / report补充元信息并产出报告。prompt-samples的生成器在测试中模拟了process()的运行时路径prompt-samples.test.tsdetectTech()产出项目级标签列表场景中即detectedTagsassemblePrompt()组装系统提示词半段——核心提示词 按批次语言过滤后的技术高亮 按批次 Slug 过滤后的审查备注 可选的 INFO.md 与 promptAppendbuildInvestigatePrompt()在 agents/shared.ts 中在外层追加真实文件清单、逐文件调查步骤与 JSON 输出规范。也就是说这份.md文件 组装器产出的一半 Agent 层包装的一半缺一不可。过滤机制的底层实现语言维度与 Slug 维度过滤是整个场景的灵魂。它由 packages/processor/src/prompt/assemble.ts 中的renderFrameworkSection实现const langSet batchLanguages batchLanguages.length 0 ? new Set(batchLanguages) : null; const knownHighlights detectedTags .map((t) highlightForTag(t)) .filter((h): h is TechHighlight h ! undefined) .filter((h) { if (!langSet) return true; // no filter → keep all return h.languages.some((l) langSet.has(l)); });核心逻辑每份技术高亮都声明了自己适用的languages数组见 highlights.ts。当批次语言集合与某高亮的语言声明存在交集时该高亮才被保留。JS/TS 系框架统一声明/** Languages most JS/TS frameworks apply to — all four extension flavors. */ const JS_LANGS [typescript, javascript];而 Django 高亮只声明languages: [python]、Rails 只声明languages: [ruby]。于是场景 05 中批次语言为[typescript]→ Next.js、React、Express 的高亮因languages与{typescript}相交而被保留Djangopython、Railsruby因无交集被丢弃。而批次语言本身由 file-language.ts 根据扩展名推断——.ts、.tsx、.cts、.mts都映射为typescriptconst EXT_TO_LANGUAGE: Recordstring, string { .ts: typescript, .tsx: typescript, // ... .py: python, .rb: ruby, // ... };languagesForBatch()汇总批次全部文件的语言并做排序去重。对未知扩展名如 Dockerfile、配置文件返回null此时组装器按无语言信息处理保留所有合格高亮——这是刻意设计。Slug 维度的过滤在renderSlugSection只有batchSlugs中出现的 slug 才会查表注入一行审查备注slug-notes.ts使提示词长度随扫描器实际命中情况伸缩而不是永远携带整个漏洞注册表。此外assemble.ts还设有FRAMEWORK_SECTION_CHAR_BUDGET 6000的字符预算超限时放弃全部高亮、退化为一行本仓库使用 N 个已知框架的摘要对应场景 07 的 overflow-fallback 设计。提示词正文逐段解析下面按提示词的实际顺序逐段继承原文并配以实现层面的解读。这段文本就是 Agent 在场景 05 中收到的完整指令。1. 角色设定与任务边界You are a world-class security researcher with deep expertise in web application security, authentication systems, and modern application frameworks across many languages. You think like an attacker: you look for subtle logic flaws, not just textbook vulnerabilities. You have a track record of finding bugs that automated tools miss — race conditions, auth bypasses via parameter manipulation, and trust boundary violations. An automated scanner has identified these files as **candidates** worth investigating. The scanner uses regex and heuristic patterns to cast a wide net — many candidates will be false positives, but some will be real vulnerabilities. Your job is to perform a thorough, open-ended security review. Use the flagged patterns as starting points, then investigate each file for ANY security issue you can find — especially the subtle ones that only an expert would catch. **Static analysis only.** Do NOT attempt to reproduce, exploit, or trigger any vulnerability. Do not run the target code, send requests against any endpoint, or execute proof-of-concept scripts. Review the source code only.这段来自 core.ts 中的CORE_PROMPT是框架无关的通用核心。它做了三件事把 Agent 定位为攻击者思维的安全研究员明确扫描器候选仅是线索、审查必须开放发散强制限定为纯静态分析禁止复现与利用——这是 Deepsec 合规红线也是该提示词可直接复用于任何审计任务的原因。2. 严重性分级标准Security severities (exploitable by an attacker): - **CRITICAL**: Remote Code Execution (RCE), authentication bypass allowing full access, SQL injection on sensitive data, unrestricted file upload leading to RCE, SSRF to internal services - **HIGH**: Cross-Site Scripting (XSS), Server-Side Request Forgery (SSRF), privilege escalation, hardcoded secrets/credentials in source code, insecure deserialization, missing authorization on sensitive operations - **MEDIUM**: Open redirect, weak cryptographic algorithms, missing rate limiting, information disclosure, insecure direct object references, race conditions, logic bugs in auth/permission checks Non-security bugs worth reporting alongside security findings: - **HIGH_BUG**: Major non-security bugs that could cause data loss, corruption, outages, or seriously broken behavior - **BUG**: Notable non-security bugs (logic errors, race conditions, resource leaks) that dont rise to HIGH_BUG分级标准刻意区分了安全漏洞CRITICAL/HIGH/MEDIUM强调可被攻击者利用与非安全缺陷HIGH_BUG/BUG关注数据丢失、宕机、逻辑错误。注意 HIGH 与 MEDIUM 之间的分界XSS、SSRF、越权、硬编码密钥属于 HIGH而开放重定向、弱加密、缺限流、竞态条件这类非直接取走数据的问题归为 MEDIUM。这一分级在后续 Agent 输出 JSON 的severity字段中严格对应并由核心包的findingSchema校验见 packages/core/src/schemas.ts 相关实现。3. 已知漏洞类别注册表| Slug | Category | |------|----------| | auth-bypass | Authentication checks that can be circumvented | | missing-auth | HTTP endpoints without authentication | | acl-check | Missing or incorrect RBAC/permission checks | | xss | Cross-site scripting via innerHTML, dangerouslySetInnerHTML, etc. | | dangerous-html | Unsafe HTML rendering with user-controlled data | | rce | Remote code execution via exec, eval, spawn, etc. | | sql-injection | SQL injection via string interpolation/concatenation | | ssrf | Server-side request forgery via user-controlled URLs | | path-traversal | File operations with user-controlled paths | | secrets-exposure | Hardcoded API keys, tokens, passwords | | insecure-crypto | Weak hash algorithms, insecure random generation | | open-redirect | Redirects to user-controlled URLs | | unsafe-redirect | Redirects bypassing validation functions | | public-endpoint | Public endpoints exposing sensitive data without auth | | service-entry-point | Service handlers that may lack proper auth | | webhook-handler | Webhook endpoints without signature verification | | iam-permissions | Misconfigured IAM Action/Resource permissions | | jwt-handling | JWT signing/verification misconfigurations | | env-exposure | Secrets leaking to client bundles | | rate-limit-bypass | Sensitive operations without rate limiting | | cache-key-poisoning | Cache keys including attacker-controlled values | | secret-env-var | Direct access to secret environment variables | | cross-tenant-id | User-supplied IDs in DB lookups without ownership check | | secret-in-fallback | Secret env vars with hardcoded fallback values | | secret-in-log | Credentials in log statements or error responses | | expensive-api-abuse | Endpoints calling expensive APIs (LLM, AI, paid services) without abuse protection | | other-* | Any other vulnerability not listed above (use descriptive suffix) |这张表是 Agent 输出中vulnSlug字段的受控词表。它明确告知 Agent扫描器只找这些模式但你应当找出全部漏洞无论扫描器是否标记。other-*后缀允许发现表外漏洞时自定义命名如other-race-condition为开放审查留出出口。这些 Slug 与 packages/scanner/src/matchers 下数以百计的匹配器一一对应例如本场景涉及的js-express-route匹配器位于 js-express-route.ts、xss位于 xss.ts。4. 误报抑制指导False Positive GuidanceBefore classifying an issue, check for mitigations: - Is the input sanitized or escaped before use? (parameterized queries, HTML escaping) - Is there middleware or a framework guard that protects this code path? - Is the vulnerable pattern only used with trusted/internal data, not user input? - For auth checks: only middleware that *wraps the handler directly* counts (Express middleware, Fastify hooks, NestJS guards, Spring filters, Rails before_action, Django decorators, FastAPI Depends). Edge/proxy/CDN/WAF rules and front-of-stack middleware that runs BEFORE the handler are NOT sufficient on their own — too easy to misconfigure or bypass via routes that escape the matcher. - For redirects: is there an explicit allowlist or origin check before the redirect? If fully mitigated, do NOT flag it. Report only genuine, exploitable vulnerabilities.这是 Deepsec 控制误报率的关键设计扫描器撒大网Agent 收网时必须有豁免意识。其中关于认证中间件的判定标准值得特别注意——只有直接包裹处理器的中间件才算数Express 中间件、Fastify hooks、NestJS guards、Spring filters、Rails before_action、Django 装饰器、FastAPI Depends而边缘/代理/CDN/WAF 规则或位于处理器之前的前置中间件单独不足以豁免因为它们太容易被路由绕过。这一规则也原样出现在各框架的技术威胁高亮中。5. 认证绕过模式清单### Query String URL Manipulation - **Parameter pollution**: Can duplicate query params (e.g., ?teamIdxteamIdy) change behavior or bypass checks? - **Encoded characters**: Does the app handle URL-encoded, double-encoded, or Unicode-normalized paths correctly? (%2F vs /, %00 null bytes) - **Route param injection**: Can dynamic route segments be manipulated to access other users data? - **Token refresh abuse**: Query params that force token refreshes — are they rate-limited? ### Auth Flow Bypasses - **OAuth callback manipulation**: State parameter tampering, redirect_uri manipulation, custom URI scheme injection - **Session/JWT weaknesses**: Missing algorithm pinning, stub sessions when auth not configured, test tokens reachable in prod - **Header injection**: Auth headers like X-Forwarded-For, Authorization, custom x-* tokens — are they validated or trusted blindly? ### Authorization Gaps (has auth, wrong auth) - **Cross-tenant access**: User-supplied teamId/userId used in DB queries instead of the authenticated identity - **Missing resource-level checks**: Auth confirms user is logged in but doesnt verify user owns this resource - **Negated permission checks**: !(await auth.can(...)) with inverted logic这组模式把看起来有认证的代码也纳入审查范围覆盖三类隐蔽绕过URL/查询串操纵参数污染、双重编码、路由参数注入、认证流程缺陷OAuth state 篡改、JWT 算法未固定、盲目信任转发头、以及授权缺口跨租户访问、缺少资源级所有权校验、取反逻辑错误。它与auth-bypass、cross-tenant-id等 Slug 形成呼应——扫描器标记出候选后Agent 用这份清单深挖绕过路径。6. 范围外文件规则Skip files that are gitignored, generated, vendored, or not production code. If a file is in dist/, node_modules/, vendor/, generated/, or matches .gitignore, return an empty findings array for it.对非生产代码返回空 findings 数组empty findings array而不是报错或臆造——这与输出规范中的无真实漏洞时给出空数组衔接保证 JSON 结果可被下游无歧义消费。7. 技术栈威胁高亮本场景保留下来的三份这是场景 05 与场景 04 的决定性差异所在。项目整体虽带django、rails标签但批次是 TypeScript故只注入以下三份原文完整继承Next.js- Next.js middleware.ts runs at the edge and is NOT sufficient auth — too easy to misconfigure or bypass via routes that escape the matcher - Server Actions are publicly callable POST endpoints — every one needs explicit auth authorization checks - JSON.stringify() inside dangerouslySetInnerHTML or inline script tags is XSS unless the output escapes / (look for safeJsonStringify or \u003c) - searchParams and dynamic route segments ([id], [...slug]) are user-controlled — treat them as untrusted in middleware too - unstable_cache / revalidateTag on user-supplied keys can leak across tenantsReact- dangerouslySetInnerHTML with any user-influenceable string is XSS — DB values and usernames count as user-controlled - Refs and effects that touch document.location / window.opener can become open-redirect or tabnabbing sinks - Server-rendered JSON in script tags must escape / to be XSS-safeExpress.js- Each app.get/post/... and router.use is a public endpoint — confirm auth middleware actually wraps it (order matters; routes mounted before app.use(authMiddleware) are unprotected) - req.query/req.params/req.body are user input; concatenation into SQL, shell, paths, or URLs is the usual sink - express.static on a user-influenced root, or res.sendFile(req.params.x), is path traversal - Error handlers that send err.stack or err.message to the response leak internals - CORS origin: true reflecting credentials enables CSRF-via-fetch这些条目来自 highlights.ts 中TECH_HIGHLIGHTS数组的bullets字段。注释里写明硬性约束每条 3–6 个要点、约 80–200 token由 CI 快照测试守护大小反对写成教程式长文——高亮的作用是指向扫描器看不到的威胁而非教学。作为对照场景 04同仓库、纯 Python 批次注入的则是 Django 高亮Next.js/Express/Rails 全部被过滤——两场景并读即可直观看到语言过滤的效果。8. Slug 特定审查者备注- all-server-actions: Server Actions are public POST endpoints; flag any that dont explicitly check auth ownership. - js-express-route: Weak entry-point candidate — confirm the handler reads req.* data AND lacks an auth wrapper / validator before flagging. - xss: Check escape state at every step; raw concat into HTML, JSON-in-script without /-escape, and ref.innerHTML are the usual sinks.三条备注均来自 slug-notes.ts规则是每个 Slug 一句话、指明报之前该查什么。特别值得注意的是js-express-route的备注措辞Weak entry-point candidate弱入口候选——框架入口匹配器本身不构成漏洞必须确认处理器读取了req.*数据且缺少认证包装/校验器才能上报。这与误报指导中确认真实输入→汇点路径且缺认证/校验的口径完全一致防止把每个路由注册都当成漏洞。9. 目标文件清单Agent 层注入- **apps/web/app/api/login/route.ts** - [all-server-actions] L9: POST handler — auth check - **apps/api/src/server.ts** - [js-express-route] L12, 18, 24: app/router method registration - [xss] L40: innerHTML这一段由 agents/shared.ts 的buildInvestigatePrompt渲染对每个FileRecord列出文件路径候选命中以- [slug] L行号: 匹配模式的缩进格式呈现。行号与模式来自场景定义中的candidates数组prompt-samples.fixtures.ts例如login/route.ts在第 9 行有一个POST handler — auth check的 Server Action 候选server.ts有 12/18/24 三处 Express 路由注册和 40 行的 innerHTML 候选。若文件无任何候选命中则渲染为(no scanner hits — full holistic review)提示 Agent 做全量审查而非追问候选在哪——这是process --diff等直接调用场景的兜底设计。10. 调查步骤与输出规范For each file: 1. **Read the file fully** using the Read tool 2. **Trace data flows** — where does input come from? Is it user-controlled? 3. **Follow imports** — read related files (middleware, utils, shared libs) to understand the full picture 4. **Check for mitigations** — is there sanitization, validation, auth middleware, or framework protection? 5. **Think broadly** — look for issues beyond what the scanner flagged. The scanner only finds surface patterns; you should reason about logic bugs, race conditions, missing checks, etc.输出格式要求 Agent 为每个文件返回一个 JSON 块字段包括filePath、severity五级枚举、vulnSlug、title、description、lineNumbers、recommendation、confidencehigh/medium/low。这份 JSON 随后由parseInvestigateResultsagents/shared.ts解析先做严格 JSON.parse失败则用jsonrepair做容错修复每个 finding 再经核心包的findingSchema做字段级校验非法字段会触发同会话的 field-repair 追问轮runInvestigateFieldRepairLoop避免一个坏字段抹掉整文件结果的静默丢失。若某文件确无漏洞必须以空findings数组返回保证结果数组与批次文件一一对应。提示词样例如何保持与实现同步这些.md快照的价值在于确定性可复现。prompt-samples.test.ts 对每个场景执行两件事通过fullPromptFor(scenario)实时调用assemblePromptbuildInvestigatePrompt生成期望提示词与磁盘上的样例文件逐字节比对expect(onDisk).toBe(expected)。任何对组装器、高亮文本、Slug 备注或 Agent 层的改动都会导致快照测试失败。当改动是有意为之比如新增一条 Next.js 威胁要点时维护者设置环境变量重新生成并审查 diffUPDATE_PROMPT_SAMPLES1 pnpm test:unit测试文件还额外守护了两条不变量02-nextjs-tsx-batch样例必须同时包含组装器产出的核心段落与 Agent 层产出的文件清单/输出格式08-with-info-and-append样例中 INFO.md 内容在全提示词中恰好出现一次防止代理层与组装器重复注入。这套机制保证了提示词长什么样永远是代码当前行为的忠实投影而非过期的手写文档。场景横向对比理解过滤边界的四种形态将场景 05 放在PROMPT_SAMPLE_SCENARIOSprompt-samples.fixtures.ts的图谱中可以清晰看到组装器的四种形态场景仓库技术批次高亮注入结果02-nextjs-tsx-batchnextjs/react/node.tsx 文件Next.js React 高亮04-polyglot-python-batch六栈 polyglot纯 Python仅 Django 高亮05-polyglot-typescript-batch六栈 polyglot纯 TypeScript仅 Next.js / React / Express06-polyglot-mixed-batchnextjs/react/django/gin/nodeTS Python Go 混合各自语言对应的高亮同时注入07-overflow-fallback全部已知框架Dockerfile无语言超出字符预算退化为一行摘要这张表揭示的设计哲学是提示词大小与信息密度始终跟随本轮要审什么而不是仓库里有什么。同一仓库的 Python 批次与 TypeScript 批次会收到完全不同、但各自精准的威胁清单既避免了无关框架噪音稀释模型注意力也控制了 token 成本。而 07 号场景的预算兜底则说明当所有框架同时命中且超出 6000 字符预算时宁可只说本仓库用了 N 个已知框架注意跨框架信任边界也不让提示词臃肿到模型抓不住重点。实战价值这份提示词能复用到哪里虽然本仓库中的场景 05 是测试夹具但它揭示的提示词工程方法可直接落地到任何AI 辅助代码审计场景角色 边界先给模型明确身份攻击者思维研究员和硬约束仅静态分析杜绝利用性输出受控词表 开放出口vulnSlug用固定注册表保证输出可机器解析同时允许other-*自定义命名兼顾结构化与开放性误报三道闸输入净化、框架守卫、可信数据豁免——任何一条成立就不上报上下文裁剪按批次语言过滤框架高亮、按命中 Slug 过滤审查备注是控制提示词长度与聚焦度的通用手段确定性输出协议强制 JSON 结构 空数组占位 后续字段级校验使模型输出能直接进入结构化流水线。如果要在自己的审计流水线中复刻只需把CORE_PROMPTcore.ts作为通用底座参照TECH_HIGHLIGHTS与SLUG_NOTES维护两套条件注入的字典再用buildInvestigatePrompt的模板补上文件清单与输出规范即可——这正是 Deepsec 处理器在生产中运行的完整路径而本场景样例就是这条路径的忠实快照。延伸阅读场景定义与生成入口packages/processor/src/tests/prompt-samples.test.ts、prompt-samples.fixtures.ts提示词组装器与预算控制packages/processor/src/prompt/assemble.ts框架高亮字典含语言声明packages/processor/src/prompt/highlights.ts漏洞 Slug 备注字典packages/processor/src/prompt/slug-notes.ts语言推断与批次语言计算packages/processor/src/prompt/file-language.tsAgent 层包装与结果解析packages/processor/src/agents/shared.ts技术栈检测器标签来源packages/scanner/src/detect-tech.ts对照场景Python 批次prompt-samples/04-polyglot-python-batch-filters-other-techs.md整体流水线docs/architecture.md赞分享应用安全漏洞扫描人工智能AI Agent【免费下载链接】deepsecDeepsec is a security harness for finding vulnerabilities in your codebase powered by coding agents项目地址https://gitcode.com/gh_mirrors/deeps/deepsec点击查看免费下载相关推荐Deepsec 多语言混合批次Polyglot Mixed Batch审查提示词解析TypeScript Python Go 同批安全审查的按语言高亮过滤机制Deepsec 多语言混合批次Polyglot Mixed Batch审查提示词解析TypeScript Python Go 同批安全审查的按语言应用安全漏洞扫描人工智能AI Agent读懂 Deepsec 的 AI 安全审查提示词以 Next.js TSX 批量审查样本为例读懂 Deepsec 的 AI 安全审查提示词以 Next.js TSX 批量审查样本为例 导读 本文围绕 Deepsec 开源仓库中的 prompt s应用安全漏洞扫描人工智能AI Agent多语言提示词设计中文语境下的提示工程终极指南多语言提示词设计中文语境下的提示工程终极指南 在全球化AI应用时代多语言提示词设计已成为开发者必备技能。GitHub推荐项目精选cours/courses示例工程上一篇lumberjackGo 滚动日志文件库Rolling File Logger原理与实战下一篇PurpleLab与MITRE ATTCK联动教程战术矩阵可视化与攻击路径分析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考