SuperAPI AI Directory
Partner中文AI newsFavorites
Skillsarkweb-security-patch-impact

arkweb-security-patch-impact

Security & auditing

View repository

Updated 10-16 03:11

About this skill

ArkWeb Impact Analysis

Used for arkweb-security-patch-impact-decider。

When to use this skill

Use this skill after issue analysis and patch fetch are complete. It maps upstream fix facts to the configured ArkWeb baseline and produces the final affected/unaffected/unknown decision, ownership routing, feature impact, risk and test recommendations.

Input

  • .ace-outputs/{runId}/{issue_id}/01_issue_analysis.md
  • .ace-outputs/{runId}/{issue_id}/01_issue_analysis.json
  • .ace-outputs/{runId}/{issue_id}/02_patch_fetch.md
  • .ace-outputs/{runId}/{issue_id}/02_patch_fetch.json
  • Optional ArkWeb local repository path: used only when either the context.automation.repoPath、context.codebase or the context.projectRoot field in the current workflow context is explicitly configured; select the first non-empty valid path in that order.
  • Default responsibility field configuration:references/team_definition.yaml
  • Default feature tree configuration:references/feature_tree_list.txt
  • If context.requirements specifies a project-specific responsibility field or feature tree configuration, the user-specified configuration takes precedence; otherwise, use the above default references.
  • The impact analysis field template is based on the built-in skill description and does not depend on external reference directories.

Analysis Entry

Impact analysis must start from three pieces of evidence and converge on a conclusion in order:

  1. Issue evidence: read 01_issue_analysis.* the issue fields, labels, comment timeline, Milestone, FoundIn, Merge-Request, Merge-Approved, Merged, FixedIn, fix clues, and security attributes extracted from the local HTML/MHTML, to determine the upstream problem context, version signals, and information gaps.
  2. PR/CL evidence: read 02_patch_fetch.* the confirmed selected fix, Gerrit/Gitiles/PR/commit, patch, and modified_files, and verify which branches the fix actually landed on; this determines the status of mainline fixes, cherry-picks, release branches, branch-head, requested/approved/merged, and so on.
  3. Project root directory code evidence: based on the context.codebase in the current workflow context, inspect the current project code to confirm whether the corresponding files, symbols, call chains, compilation switches, platform trimming, or equivalent implementations exist; this determines whether the current ArkWeb project is affected.

The final report must write the basis for the conclusion as these three evidence chains:Issue -> PR/CL -> context.codebase 源码核验 -> ArkWeb 影响结论。

Output

Write to the same issue directory:

  • .ace-outputs/{runId}/{issue_id}/03_impact_decision.md
  • .ace-outputs/{runId}/{issue_id}/03_impact_decision.json

No files may be written to the root directory; do not generate 03_impact_decision.index.md/json or root-level 03_impact_decision.md/json。

Detailed output structure is in references/impact-output.md.

Must cover:

  1. Chromium upstream affected version conclusion: clearly list which Chromium milestones, branches, or version ranges are affected by this vulnerability/fix; when it cannot be pinned down to a version, you must state unknown。
  2. Basis for the Chromium version conclusion: cite evidence such as issue metadata, merge/milestone labels, fix CL/commit, branch-head, release notes, commit times, or the branch where the patch resides, and distinguish facts, inferences, and gaps.
    • Milestone / M-* / Target-* indicates the target fix milestone or the version intended to be resolved, and cannot by itself be equated with an "affected version" or a "fixed version".
    • Labels is a set of labels and must be broken down according to the meaning of each specific label;Type-*、Security_Severity-*, component labels cannot directly lead to a version impact conclusion.
    • FoundIn-* indicates a confirmed affected milestone; when multiple exist, the earliest FoundIn-* is important evidence for the starting point of impact.
    • Merge-Request-* / Request-* only indicates that a merge to the corresponding milestone branch was requested, and does not mean it has been approved or landed.
    • Merge-Approved-* / Approved-* indicates that the merge request has been approved, and does not mean the cherry-pick has been committed to the branch.
    • Merged-*, a cherry-pick commit on branch-head, or the commit record of the fix CL on the corresponding release branch, can serve as strong evidence that "the branch has been fixed".
    • FixedIn-* can only serve as a supporting signal and must be cross-validated with the branch into which the fix CL/PR actually merged, the commit message, the cherry-pick source, or branch-head evidence.
  3. PR/CL branch merge verification: based on 02_patch_fetch.json selected fix, Gerrit/Gitiles/PR/commit links, and patch metadata in the issue to confirm the mainline commit, cherry-pick commit, target branch-head, or release branch; do not draw a final version conclusion based solely on the issue label.
  4. The relative relationship between the current ArkWeb baseline and the upstream fix version.
  5. Based on the current workflow context's context.codebase perform local engineering source verification, checking whether the files, symbols, call chains, build switches, platform tailoring, or equivalent implementations corresponding to 02_patch_fetch.json.modified_files[] exist.
  6. Clearly state the current ArkWeb engineering conclusion:affected、unaffected、unknown choose one of the three, and explain its relationship with the Chromium version impact scope.
  7. Every key conclusion must have a written evidence chain:Issue 证据 -> PR/CL 实际合入分支或缺口 -> 当前 ArkWeb 源码核验证据 -> 结论。
  8. Affected modules, product surface, security, compatibility, stability, performance, RAM, ROM, and business logic correctness risks.
  9. Ownership assignment: the team name must be copied verbatim from the valid team names in the available ownership configuration.
  10. Affected features: the complete line must be copied verbatim from the available feature tree configuration, in the format 团队名 > 一级业务特性 > 二级业务特性 > 三级业务特性, and inventing paths is prohibited.
  11. Fix priority, fix complexity, whether retention is recommended, whether testing is needed, and testing recommendations.
  12. If the issue is security-related, a dedicated security impact analysis must be output: vulnerability category, attack surface, trigger conditions, exploitability, security boundaries such as permissions/sandbox/privacy/certificates, consequences of not fixing, basis for the risk level, and security testing recommendations.
  13. If it is determined to be unaffected, auditable evidence must be provided; for security-related issues, it must also explain why the security chain is unreachable, why the corresponding code does not exist, or why the platform does not expose it.

Team and feature routing rules are in references/team-feature-routing.md. Use references/team_definition.yaml and references/feature_tree_list.txt as the default routing data.

Scripts

You may preferentially use scripts distilled from the verified logic of this archived workflow to generate 03_impact_decision.md/json, and do not regenerate temporary Python scripts at runtime:

python3 skills/arkweb-security-patch-impact/scripts/generate_impact_decision.py \
  --project-root <context.codebase> \
  --output-root <context.projectRoot>/.ace-outputs/<runId> \
  --feature-tree skills/arkweb-security-patch-impact/references/feature_tree_list.txt

The script will read <context.projectRoot>/.ace-outputs/<runId>/{issue_id} in 01_issue_analysis.json and 02_patch_fetch.json, and write back to 03_impact_decision.md/jsonin the same directory. The script output directory uses context.projectRoot, and source verification uses context.codebase; the script only performs path matching, version evidence organization, preliminary ownership/feature tree judgment, and a security-specific skeleton. The agent must continue to review version branches, source semantics, and security impact, and must not treat script output as a final conclusion exempt from review.

Field ownership boundaries:

  • At this stage, the Chromium upstream affected version range and its basis must first be provided, and then combined with context.codebase the current engineering source to give the ArkWeb impact conclusion.
  • At this stage, the actual merge branches of the PR/CL/commit already identified in the products of the first two steps must be reviewed; it is allowed to supplement verification of branches, commits, and cherry-pick relationships, but another main fix patch must not be reselected.
  • At this stage, the following must be filled in: ArkWeb impact conclusion, the five properties/RAM/ROM/business correctness judgment, ownership, feature tree, risk level, retention recommendation, and testing recommendations.
  • At this stage, only the products of the first two steps are read as factual basis; patches are not re-fetched, and the patch file list is not rewritten.

Note

  • It is necessary to parse "whether forced merge: yes/no" from the Web page requirement description context.requirements . If it parses as "yes", the true arkweb_impact and evidence chain must still be written truthfully, but 03_impact_decision.json must be written into merge_policy.force_merge=true、merge_policy.impact_mode=force_affected、merge_policy.source=requirements and the reason; if it parses as "no", it must be written into merge_policy.force_merge=false。
  • Do not draw conclusions based only on version numbers; it is necessary to combine file paths, build switches, and ArkWeb adaptation layer differences.
  • Do not rely only on Milestone、Merge-Request-*、Merge-Approved-*、FixedIn-* Conclusion at the individual information level; must be combined with the actual branch into which the PR/CL was merged and evidence from the current project source code.
  • It must not be taken that context.automation.repoPath being empty alone is equivalent to no local repository path being configured; you must continue checking context.codebase。
  • When the ArkWeb local repository path is not explicitly configured, you must not access, reference, or guess any fixed local ArkWeb path; conclusions involving the existence of local code or patch apply/reverse-check should be marked as unknown or pending verification.
  • Security-related issues cannot merely state “security-related: yes/no”; a dedicated analysis must be provided based on the ArkWeb exposure surface, patch modification paths, and runtime boundaries.
  • 归属团队 must exactly match a legal team name in the available responsibility field configuration.
  • 影响的特性 must be copied verbatim as the complete line from the available feature tree configuration.