# Journal Review

> Use when reviewing JSON vulnerability journals for 1C-Bitrix Site Manager or boxed Marketplace modules, especially when scanner severity may ignore Bitrix admin/content-editor trust boundaries.

- Skill: `bitrix-tools/journal-review` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add bitrix-tools/journal-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/bitrix-tools/journal-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: bitrix-tools (https://skillmd.com/u/bitrix-tools)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/bitrix-tools/journal-review

---


# Bitrix Vulnerability Journal Review

## Purpose

Use this skill to review a vulnerability journal in the AI-security JSON format, rationally re-score findings for [[1С-Битрикс Управление сайтом]] / boxed Marketplace modules, and produce a corrected journal with deterministic schema validation.

The core distinction is **raw journal severity** vs **BUS-aware triage severity**. Never present raw scanner `high` as the final risk until source permissions, version scope, and exploitability are reviewed.

## Expected Input Format

The journal must be JSON with:

- top-level `success`
- `data.vulnerabilities[]`
- each vulnerability containing at least:
  - `file`
  - `line`
  - `type`
  - `severity`
  - `description`
  - `recommendation`
  - `fix`

The script preserves all vulnerability fields, changes only `severity`, and adds a `reviewed` object.

## Required Workflow

1. Inspect the journal at a high level:
   - count findings by type/severity;
   - split `.last_version` from versioned update folders like `1.10.8`;
   - identify whether current publication triage should focus on `.last_version`.
2. Run deterministic review and validation:

```bash
python3 <skill-dir>/scripts/review_journal.py input.json --output reviewed.json
```

3. Read `data.reviewSummary` from the output JSON.
4. Explain the difference between raw journal severity and reviewed severity.
5. If the user asks for a human report, summarize:
   - raw counts;
   - reviewed counts;
   - current `.last_version` counts;
   - high-to-low/medium downgrades and why.

## Triage Rules

Use the script's categories as the source of truth; the model may add contextual commentary but must not silently override the generated JSON without re-running validation.

| Condition | Reviewed severity |
|---|---|
| IDOR/mass assignment without owner check, available to anonymous/site user, causing privileged or monetary action | `high` |
| Direct financial business-logic damage without authorization: price/quantity/discount/coupon/bonus manipulation in basket/order/payment sinks | `high` |
| Confirmed backdoor: suspicious obfuscation plus exec/network/file/exfiltration sink | `high`; obfuscation alone is not a finding |
| SQL injection | `medium` unless impact is proven beyond the journal text |
| Cross-privilege stored XSS: lower-privileged data executes in administrator/moderation/order UI | `medium` |
| Reflected XSS | `medium` |
| CSRF on meaningful state-changing action | `medium` |
| Authenticated privilege escalation, authenticated IDOR, session-dependent Open Redirect, limited blind SSRF, weak security-token crypto, sensitive TOCTOU/race | `medium` |
| OAuth/API-Key/bearer token exposed to frontend | keep at least `medium`; mention conditional validation if token may be a public ID |
| Stored XSS through trusted Bitrix admin/content editor fields | `low` hardening unless low-privileged/external source is proven |
| Open redirect controlled by trusted content property or mere `LocalRedirect` usage | `low` or not a bug without controllable external URL |
| `__FILE__`/absolute path disclosure | `low` |
| Hardcoded default/demo external token | `low` unless real secret scope is confirmed |

## Reviewed Node

Every output vulnerability must include:

- `oldSeverity`
- `newSeverity`
- `changed`
- `category`
- `versionScope`
- `version`
- `currentVersionRelevance`
- `action`
- `confidence`
- `rationale`

## Validation Requirement

Validation must be done by `scripts/review_journal.py`, not by model inspection. Before claiming the corrected journal is valid, run either:

```bash
python3 <skill-dir>/scripts/review_journal.py input.json --output reviewed.json
```

or:

```bash
python3 <skill-dir>/scripts/review_journal.py --validate-only reviewed.json
```

Do not claim the structure is correct unless the script exits successfully.

## Common Mistakes

- Treating every raw `high` XSS as a final blocker. In BUS, a content editor/admin often already has legitimate ways to publish HTML/JS.
- Treating historical update-package findings as current `.last_version` blockers.
- Dropping original fields from vulnerability entries. Only `severity` may be replaced; all other original fields must remain unchanged.
- Deciding `ACCESS_TOKEN` exposure by name alone. Confirm whether it is an OAuth/API-Key/bearer token or only a public counter/widget/model ID.