Li_codeQL_LLM

• Outcome: Review
• Latest audit: Sep 12, 2026 · 6:48 AM UTC
• Version: 1.0.0

Overview

The skill is a plausible CodeQL security scanner, but it handles scan results and CI credentials in ways that are broader and less clearly controlled than its privacy claims suggest.

Review before installing. Use only on code you are authorized to scan, do not copy the included Jenkins credentials or tokens, rotate them if they were ever real, avoid running the Jenkins automation scripts against production, keep CSRF protections enabled, and treat SARIF/reports as sensitive because they may be sent to an LLM or Jenkins despite local-only privacy claims.

A.I.G

Vulnerability Patterns

• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions

Findings (8)

T09 · Insecure Skill Coding Practices

Error

• Location: verify_skill.py:164
• Finding: Hardcoded Jenkins API Token Used by Executable Verification Code## Vulnerability Details **File Location**: `verify_skill.py:164-171` **Vulnerability Type**: Hardcoded reusable credential **Risk Level**: High ### Vulnerable Code ```python jenkins_url = "http://localhost:8080" jenkins_user = "devops" jenkins_token = "110ffb6071ded434a52bd153217f3fc873" try: response = requests.get( f"{jenkins_url}/job/codeql-security-scan/api/json", auth=(jenkins_user, jenkins_token), timeout=10 ) ``` The same token is also disclosed repeatedly in tracked documentation, including: - `Jenkins_Pipeline_更新指南.md:254-260` - `最终完成报告.md:159,188,250` - `配置完成报告.md:21,71,115,193` - `配置检查完成报告.md:107` - `配置检查报告.md:74` The repository also documents `devsecops` as a Jenkins or Gitea password/token in several files. ### Technical Analysis A reusable Jenkins credential is embedded directly in executable code and copied into documentation. Repository readers, package consumers, build-log viewers, and anyone with access to repository history can recover it. The code actively sends the credential using HTTP Basic Authentication. Basic Authentication encodes rather than encrypts the username and token, so confidentiality depends entirely on TLS. Here, the configured URL uses plaintext HTTP. The effective privileges depend on the Jenkins permissions assigned to the `devops` account. They may include reading job configuration, triggering builds, changing pipelines, accessing artifacts, or executing build-controlled commands. ### Attack Path 1. An attacker obtains the Skill package or its repository history. 2. The attacker extracts the hardcoded username and token. 3. The attacker identifies a reachable Jenkins instance using the documented address or local network discovery. 4. The attacker authenticates as `devops`. 5. The attacker performs every operation allowed to that account, such as reading jobs, triggering builds, or modifying pipelines if the token ...[truncated 401 chars]
• Remediation: ## Remediation Suggestions 1. Revoke and rotate the exposed Jenkins token immediately. 2. Rotate the documented Gitea and Jenkins passwords if they were ever active. 3. Remove credentials from current files and purge them from repository history. 4. Load credentials from a Jenkins credential binding, operating-system keyring, or dedicated secret manager. 5. Replace all documentation values with unmistakable placeholders. 6. Restrict the service account to the minimum required permissions. 7. Add secret scanning to pre-commit and CI workflows. 8. Review Jenkins audit logs for use of the disclosed token.

T09 · Insecure Skill Coding Practices

Error

• Location: jenkins_integration.py:123
• Finding: Jenkins Token Exposed in Process Arguments and Transmitted Over Potentially Insecure HTTP## Vulnerability Details **File Location**: `jenkins_integration.py:123-134` **Vulnerability Type**: Credential exposure through command-line arguments and insecure transport **Risk Level**: High ### Vulnerable Code ```python # Use curl for upload import subprocess curl_cmd = [ 'curl', '-u', f'{self.username}:{self.token}', '-F', f'file=@{sarif_path}', '-F', 'relativePath=codeql-results.sarif', url ] try: result = subprocess.run(curl_cmd, capture_output=True, text=True, timeout=60) ``` The client permits the following insecure default at `jenkins_integration.py:204`: ```python url = config.get('JENKINS_URL', 'http://localhost:8080') ``` ### Technical Analysis Supplying `username:token` as a `curl` argument places the secret in the child process argument list. Depending on operating-system process visibility and monitoring configuration, other local users, diagnostic software, audit systems, or process collectors may capture it. The client also accepts and defaults to an HTTP URL. When Jenkins is not strictly loopback-only, Basic Authentication credentials and uploaded SARIF data can be observed or modified by an attacker with network visibility. The code does not reject insecure non-loopback URLs. The `requests.Session` already configured by the class could perform a multipart request without exposing the token in process arguments. ### Attack Path **Local attack:** 1. A legitimate user starts a SARIF upload. 2. The token appears in the `curl` process arguments. 3. A local observer or monitoring service records the command line. 4. The observer reuses the recovered Jenkins token. **Network attack:** 1. The user configures an HTTP Jenkins address reachable over a network. 2. The Skill submits Basic Authentication and SARIF content over that connection. 3. An on-path attacker captures the request. 4. The attacker recovers the credential and sensitive vulnerabil ...[truncated 307 chars]
• Remediation: ## Remediation Suggestions 1. Replace the `curl` subprocess with a multipart upload through the authenticated `requests.Session`. 2. Require HTTPS for all non-loopback Jenkins endpoints. 3. Reject remote HTTP URLs during configuration validation. 4. Keep authentication data out of command-line arguments, URLs, logs, and exception messages. 5. Validate TLS certificates and support a configured private certificate authority where necessary. 6. Apply least-privilege permissions to the Jenkins upload account. 7. Add tests proving that tokens never appear in process arguments or logs.

T09 · Insecure Skill Coding Practices

Error

• Location: run.sh:23
• Finding: Arbitrary Shell Execution Through Sourced Environment File## Vulnerability Details **File Location**: `run.sh:23-28` **Vulnerability Type**: Shell injection through configuration parsing **Risk Level**: High ### Vulnerable Code ```bash # Load .env configuration if [ -f ".env" ]; then echo -e "${GREEN}✓ Loading .env configuration${NC}" set -a source .env set +a ``` ### Technical Analysis A `.env` file is normally expected to contain data in `KEY=VALUE` form. The `source` command instead treats the entire file as trusted Bash code. Command substitutions, functions, redirections, shell operators, and arbitrary commands inside `.env` execute with the privileges of the user running the scanner. This behavior is particularly dangerous if the project directory, Skill directory, extracted package, or generated `.env` file can be modified by another user or supplied from an untrusted archive. It is not necessary for the declared CodeQL scanning functionality. The project already contains `config_loader.py`, which parses configuration as data without executing it. ### Attack Path 1. An attacker gains the ability to create or modify the Skill's `.env` file. 2. The attacker inserts a shell payload, such as a command substitution in a variable assignment. 3. A user runs `run.sh`. 4. Bash executes the payload during `source .env`, before the security scan begins. 5. The payload inherits the runner's filesystem, network, and process privileges. ### Impact Assessment Exploitation results in arbitrary command execution as the user running the Skill. If installation or scanning is performed as root, the impact becomes full system compromise. Otherwise, the attacker can access the user's source code, configuration, tokens, SSH agent, writable files, and network-accessible services.
• Remediation: ## Remediation Suggestions 1. Do not use `source`, `.`, or `eval` to load `.env` files. 2. Use the existing data-only Python configuration parser. 3. Restrict accepted keys to an explicit allowlist. 4. Validate expected types, paths, URLs, booleans, and language identifiers. 5. Reject command substitutions, control characters, and malformed lines. 6. Check that configuration files are regular files, are not symlinks, and are owned by the expected user. 7. Require restrictive permissions for files containing credentials.

T09 · Insecure Skill Coding Practices

Error

• Location: run.sh:132
• Finding: Python Code Injection Through Output Directory Interpolation## Vulnerability Details **File Location**: `run.sh:132-151` **Vulnerability Type**: Code injection through an unquoted heredoc **Risk Level**: High ### Vulnerable Code ```bash if [ -f "${OUTPUT_DIR}/codeql-results.sarif" ]; then echo -e "${YELLOW}Vulnerability Statistics:${NC}" python3 << EOF import json with open('${OUTPUT_DIR}/codeql-results.sarif') as f: data = json.load(f) results = data.get('runs', [{}])[0].get('results', []) print(f" Total: {len(results)}") by_level = {} for r in results: level = r.get('level', 'none') by_level[level] = by_level.get(level, 0) + 1 for level, count in sorted(by_level.items()): emoji = {'error': 'Critical', 'warning': 'High', 'note': 'Medium', 'none': 'Informational'}.get(level, '') print(f" {emoji} {level}: {count}") EOF ``` `OUTPUT_DIR` is derived from the second positional argument at `run.sh:102`: ```bash OUTPUT_DIR="${2:-$OUTPUT_DIR}" ``` ### Technical Analysis The unquoted heredoc expands shell variables before Python parses the source. `OUTPUT_DIR` is inserted between single quotes but is not encoded as a Python string literal. A value containing a single quote and valid Python syntax can terminate the intended string and inject additional Python statements. The earlier use of shell quoting around filesystem commands does not protect this separate code-generation context. ### Attack Path 1. An attacker convinces a user or automation job to invoke `run.sh` with a crafted second argument. 2. The argument becomes `OUTPUT_DIR`. 3. Shell expansion inserts the value directly into the Python heredoc. 4. The injected value terminates the `with open(...)` string and adds attacker-controlled Python syntax. 5. Python executes the injected statements with the scanner user's privileges. Exploitation requires satisfying the preceding file-existence condition, which may be possible when the attacker can prepare the corre ...[truncated 327 chars]
• Remediation: ## Remediation Suggestions 1. Never interpolate user-controlled values into generated Python source. 2. Use a single-quoted heredoc delimiter and pass the path as a normal argument: ```bash python3 - "$OUTPUT_DIR/codeql-results.sarif" &lt;&lt;'PY' import json import sys with open(sys.argv[1], encoding="utf-8") as source: data = json.load(source) PY ``` 3. Canonicalize and validate output paths. 4. Reject control characters and unexpected path forms. 5. Run the scanner as an unprivileged account. 6. Add injection tests containing quotes, newlines, substitutions, and shell metacharacters.

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: codeql_llm_scan.py:120
• Finding: Unredacted SARIF Results Automatically Submitted to an LLM Agent## Vulnerability Details **File Location**: `codeql_llm_scan.py:120-159` **Vulnerability Type**: Uncontrolled transmission of sensitive scan data **Risk Level**: High ### Vulnerable Code ```python results = sarif_data.get('runs', [{}])[0].get('results', []) # Prepare analysis content sarif_excerpt = json.dumps(results[:30], indent=2, ensure_ascii=False) ``` The resulting prompt is submitted to the agent without redaction or per-transmission confirmation: ```python async with OpenClawClient.connect() as client: agent = client.get_agent("security-analyst") analysis: SecurityAnalysis = await agent.execute_structured( analysis_prompt, output_model=SecurityAnalysis, timeout=120 ) ``` Equivalent behavior exists in `analyze_with_llm.py:65-113`. The behavior contradicts `PRIVACY_AND_SECURITY.md:13-45`, which states that scan results are not sent to remote servers and that sending sensitive information requires explicit authorization. ### Technical Analysis SARIF result objects can contain source-code snippets, absolute or relative paths, vulnerability descriptions, taint-flow information, hardcoded credentials, and other security-sensitive context. The one-click scan workflow serializes the first 30 complete result objects and inserts them into an LLM prompt. There is no implemented redaction, destination disclosure, sensitivity classification, `local_only` enforcement, or explicit confirmation immediately before submission. Merely limiting the result count does not sanitize the data. Whether the OpenClaw agent ultimately uses a local or remote model depends on external configuration, but the Skill does not establish or enforce that boundary. ### Attack Path 1. A user runs the one-click scanner against a confidential project. 2. CodeQL produces findings containing sensitive source context or credentials. 3. The scanner serializes the first 30 full findings. 4. T ...[truncated 647 chars]
• Remediation: ## Remediation Suggestions 1. Make LLM submission disabled by default. 2. Display the destination and request explicit approval immediately before every submission. 3. Implement the documented `local_only` control and fail closed when the model location cannot be verified. 4. Reduce findings to minimal fields such as rule ID, severity, and sanitized relative location. 5. Remove source snippets, credentials, absolute paths, environment values, and user data. 6. Run secret detection and structured redaction before constructing the prompt. 7. Allow users to preview and edit the exact outgoing payload. 8. Update the privacy statement so it accurately describes Jenkins and LLM transmissions.

T09 · Insecure Skill Coding Practices

Warning

• Location: run.sh:101
• Finding: Documented Sensitive-Directory Exclusions Are Not Implemented## Vulnerability Details **File Location**: `run.sh:101-126` **Vulnerability Type**: Missing security control and misleading privacy configuration **Risk Level**: Medium ### Vulnerable Code ```bash # Parse arguments SOURCE_DIR="${1:-.}" OUTPUT_DIR="${2:-$OUTPUT_DIR}" if [ ! -d "$SOURCE_DIR" ]; then echo -e "${RED}Directory does not exist: ${SOURCE_DIR}${NC}" exit 1 fi mkdir -p "$OUTPUT_DIR" python3 scanner.py \ "$SOURCE_DIR" \ --output "$OUTPUT_DIR" \ --language "$CODEQL_LANGUAGE" \ --suite "$CODEQL_SUITE" ``` The underlying scanner only declares these arguments at `scanner.py:300-304`: ```python parser.add_argument('source', help='Source code directory') parser.add_argument('--language', '-l', default='python', help='Programming language') parser.add_argument('--output', '-o', default='.', help='Output directory') parser.add_argument('--db-name', '-d', default='codeql-db', help='Database name') parser.add_argument('--suite', '-s', default='python-security-extended.qls', help='Query suite') ``` However, `PRIVACY_AND_SECURITY.md` instructs users to invoke `run.sh` with repeated `--exclude` options for `.git`, `credentials`, and `.env`. ### Technical Analysis Neither `run.sh` nor `scanner.py` implements an exclusion option. In `run.sh`, the second argument is interpreted as the output directory, while additional arguments are ignored. Consequently, the documented privacy command does not apply the claimed exclusions and may instead create an output directory named `--exclude`. The configuration summary also reports `EXCLUDE_DIRS`, but the main scanner does not use it when creating the CodeQL database. ### Attack Path 1. A user follows the documented command and supplies sensitive-directory exclusions. 2. `run.sh` treats the first `--exclude` token as the output directory. 3. Remaining exclusion arguments are not passed to `scanner.py`. 4. CodeQL receives th ...[truncated 537 chars]
• Remediation: ## Remediation Suggestions 1. Implement a real repeatable `--exclude` option in both the launcher and scanner. 2. Apply exclusions before CodeQL database creation and verify the effective source set. 3. Connect `EXCLUDE_DIRS` configuration to the implemented filtering mechanism. 4. Print the effective include and exclude paths before scanning. 5. Fail when unknown or unused command-line options are supplied. 6. Add automated tests proving that excluded files do not enter the database or outgoing findings. 7. Remove unsupported documentation until the control is implemented.

T09 · Insecure Skill Coding Practices

Warning

• Location: config_loader.py:145
• Finding: Secret Configuration Saved Without Enforced Restrictive Permissions## Vulnerability Details **File Location**: `config_loader.py:145-153` **Vulnerability Type**: Insecure plaintext secret storage **Risk Level**: Medium ### Vulnerable Code ```python def save(self, path: Optional[str] = None): """Save configuration to file""" save_path = Path(path) if path else Path(self.env_file) with open(save_path, 'w', encoding='utf-8') as f: f.write("# CodeQL + LLM Scanner Configuration\n") f.write("# Generated automatically\n\n") for key, value in sorted(self.config.items()): f.write(f"{key}={value}\n") ``` ### Technical Analysis The configuration may contain `JENKINS_TOKEN` and other credentials. The `save` method writes every value in plaintext but does not enforce mode `0600`, check ownership, reject symbolic links, or perform an atomic secure replacement. Effective permissions depend on the process umask and any pre-existing file mode. A permissive environment can therefore produce a group-readable or world-readable secret file. Following a symlink could overwrite another writable target with configuration data. ### Attack Path 1. A user saves configuration while operating under a permissive umask or to an existing permissive file. 2. The file contains Jenkins or other service credentials in plaintext. 3. Another local user or process reads the file. 4. The recovered credentials are reused against the corresponding service. A local attacker who can prepare the destination path may also attempt a symlink-based overwrite within the victim's writable scope. ### Impact Assessment The direct scope is local credential disclosure and possible file overwrite within the runner's existing privileges. Recovered service credentials provide whatever Jenkins, Gitea, or related permissions were assigned to those credentials.
• Remediation: ## Remediation Suggestions 1. Prefer a dedicated secret manager or operating-system credential store. 2. If a file is required, create it atomically with mode `0600`. 3. Reject symbolic links and verify ownership before replacement. 4. Write to a securely created temporary file, flush it, and atomically rename it. 5. Store non-secret configuration separately from credentials. 6. Warn and fail when existing secret-file permissions are broader than owner-only access. 7. Avoid writing secret values to logs, reports, or documentation.

T08 · Insecure Dependencies

Warning

• Location: SKILL.md:58
• Finding: Mutable CodeQL Executable Downloaded Without Integrity Verification## Vulnerability Details **File Location**: `SKILL.md:58-60` **Vulnerability Type**: Unpinned and unverified executable dependency **Risk Level**: Medium ### Vulnerable Code ```bash wget https://github.com/github/codeql-cli-binaries/releases/latest/download/codeql-linux64.zip unzip codeql-linux64.zip -d /opt/codeql ln -s /opt/codeql/codeql/codeql /usr/local/bin/codeql ``` Equivalent instructions appear in `README.md:23-26` and multiple locations in `README_BILINGUAL.md`. ### Technical Analysis The download comes from GitHub's official CodeQL release repository, not from a personal pastebin or unknown code-hosting domain. However, the URL uses the mutable `latest` alias and the instructions do not verify a checksum or cryptographic signature. The archive is extracted into `/opt`, and its executable is linked into `/usr/local/bin`, normally requiring elevated privileges. Future scanner invocations trust and execute that binary. A compromised upstream release process, account, redirect path, or incorrectly resolved artifact could therefore introduce executable code after the Skill itself has been reviewed. ### Attack Path 1. A user follows the installation instructions, potentially with elevated privileges. 2. The mutable `latest` URL resolves to an artifact that was not part of the reviewed Skill version. 3. No checksum or signature is checked. 4. The artifact is installed into a privileged system location. 5. Later Skill runs execute the installed `codeql` binary. 6. A substituted or compromised artifact executes with the scanner user's privileges. ### Impact Assessment The installed binary receives access to every scanned source tree and CodeQL output directory. If installed or executed as root, a malicious artifact could compromise the entire host. Under an unprivileged account, it could still steal source code, credentials accessible to that user, and scan artifacts.
• Remediation: ## Remediation Suggestions 1. Pin a specific reviewed CodeQL version rather than using `latest`. 2. Publish and verify the expected SHA-256 digest before extraction. 3. Verify an upstream cryptographic signature or provenance attestation where available. 4. Download to a temporary location and inspect the archive before installation. 5. Avoid privileged installation when a user-local installation is sufficient. 6. Do not overwrite or shadow an existing system executable without explicit approval. 7. Record the exact CodeQL version and digest in the Skill metadata. 8. Prefer a trusted package-management process with integrity and provenance controls.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• YARA Signatures: Malware Match, Webshell Match, Cryptominer Match

Findings (478)

Credential Access

High

• Category: Privilege Escalation

Content

```bash
cd ~/.openclaw/workspace/skills/codeql-llm-scanner
cp .env.example .env
```

### 2. 编辑配置文件 / Edit Configuration File

• Confidence: 60% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

```bash
cd ~/.openclaw/workspace/skills/codeql-llm-scanner
cp .env.example .env
```

### 2. 编辑配置文件 / Edit Configuration File

• Confidence: 60% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Description-Behavior Mismatch

High

• Confidence: 95% confidence
• Finding: The configuration guide exposes an `exploit` analysis mode and `LLM_GENERATE_EXPLOIT=true`, which materially expands the tool from defensive analysis into offensive capability. In a CodeQL/LLM scanning skill, enabling exploit-generation increases the risk of weaponizing findings and producing actionable attack payloads against real targets.

Credential Access

High

• Category: Privilege Escalation

Content

```bash
# 1. 配置 Jenkins
cat > .env << EOF
JENKINS_URL=http://jenkins.example.com:8080
JENKINS_USER=devops
JENKINS_TOKEN=1234567890abcdef

• Confidence: 84% confidence
• Finding: While `.env` references are usually benign, this instance is part of an example that places a Jenkins token into a plaintext `.env` via heredoc. In context, it encourages insecure credential storage and possible leakage through shell history, screenshots, copy/paste, or repository commits.

Description-Behavior Mismatch

High

• Confidence: 97% confidence
• Finding: The 'target machine' example explicitly promotes exploit-oriented scanning by combining `LLM_ANALYSIS_MODE=exploit`, `LLM_GENERATE_EXPLOIT=true`, and `SECURITY_CHECK_BEFORE_SCAN=false`. This normalizes offensive use and disabling safeguards, making misuse substantially more likely in environments where the skill should remain defensive.

Credential Access

High

• Category: Privilege Escalation

Content

修复：避免使用 eval()

3. 命令注入 - vulnerable_app.py:88
   利用：; cat /etc/passwd
   修复：不使用 shell=True
```

• Confidence: 90% confidence
• Finding: The documentation includes a concrete command-injection payload targeting /etc/passwd. Even though this appears in an example, it is still actionable offensive guidance that can be repurposed by users and is more dangerous in a general-purpose skill than in narrowly sandboxed training material.

Context-Inappropriate Capability

High

• Confidence: 99% confidence
• Finding: The document publishes hardcoded Jenkins credentials and encourages their direct use in the web UI and related setup. Exposing reusable administrative or service credentials in documentation can lead to unauthorized Jenkins access, job tampering, artifact theft, and compromise of connected CI/CD systems.

Context-Inappropriate Capability

High

• Confidence: 99% confidence
• Finding: The guide explicitly instructs users to weaken Jenkins CSRF protections to make automation easier. Disabling or weakening crumb protection materially increases the risk of unauthorized state-changing requests against Jenkins, which is especially dangerous because Jenkins commonly has access to source code, secrets, and build infrastructure.

Missing User Warnings

High

• Confidence: 98% confidence
• Finding: The CSRF-disabling instructions are presented as a troubleshooting path with only a minimal 'test environment' qualifier and no prominent explanation of the security consequences. This can normalize an unsafe workaround and lead operators to apply it in environments where Jenkins is reachable by other users or systems.

Credential Access

High

• Category: Privilege Escalation

Content

## 🔧 配置说明

### .env 中的 Jenkins 配置

```ini
# Jenkins 配置

• Confidence: 97% confidence
• Finding: The .env example includes Jenkins URL, username, token/password, and auto-pipeline settings in a way that encourages storing sensitive CI credentials in plaintext configuration. Because Jenkins often controls builds and secrets, leaked .env contents could enable pipeline abuse, credential harvesting, or downstream infrastructure compromise.

External Script Fetching

High

• Category: Supply Chain

Content

### 1. 检查任务是否创建

```bash
curl -u devops:devsecops http://localhost:8080/job/codeql-security-scan/api/json
```

### 2. 触发构建

• Confidence: 90% confidence
• Finding: Remote code is downloaded and executed. This bypasses code review and could introduce malicious code.

Credential Access

High

• Category: Privilege Escalation

Content

## 🏢 Gitea 配置说明

### 获取 Gitea Access Token

1. **登录 Gitea**
   ```

• Confidence: 70% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

## 🏢 Gitea 配置说明

### 获取 Gitea Access Token

1. **登录 Gitea**
   ```

• Confidence: 70% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

## 🏢 Gitea 配置说明

### 获取 Gitea Access Token

1. **登录 Gitea**
   ```

• Confidence: 70% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

## 🏢 Gitea 配置说明

### 获取 Gitea Access Token

1. **登录 Gitea**
   ```

• Confidence: 70% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

## 🏢 Gitea 配置说明

### 获取 Gitea Access Token

1. **登录 Gitea**
   ```

• Confidence: 70% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

## 🏢 Gitea 配置说明

### 获取 Gitea Access Token

1. **登录 Gitea**
   ```

• Confidence: 70% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Missing User Warnings

High

• Confidence: 99% confidence
• Finding: The document includes a live-looking Jenkins username and API token directly in example curl commands. Embedding credentials in documentation risks credential leakage through source control, screenshots, logs, shell history, and copy/paste reuse, enabling unauthorized Jenkins access if the token is valid.

External Script Fetching

High

• Category: Supply Chain

Content

grep "mkdir -p" ~/codeql-llm-scanner/Jenkinsfile

# 2. 触发构建
curl -u devops:110ffb6071ded434a52bd153217f3fc873 \
  -X POST "http://192.168.4.53:8080/job/codeql-security-scan/build" \
  --data-urlencode "json={'parameter': [{'name':'SCAN_TARGET','value':'/root/devsecops-python-web'}]}"

• Confidence: 90% confidence
• Finding: Remote code is downloaded and executed. This bypasses code review and could introduce malicious code.

Credential Access

High

• Category: Privilege Escalation

Content

```bash
cd ~/.openclaw/workspace/skills/codeql-llm-scanner
cat .env | grep -E "JENKINS|CODEQL"
```

### 测试配置

• Confidence: 93% confidence
• Finding: The command cat .env | grep -E "JENKINS|CODEQL" encourages printing secret-bearing configuration to the terminal. This can leak credentials into terminal scrollback, logs, demos, shared sessions, or screenshots, especially because JENKINS_TOKEN is likely matched by the grep.

External Script Fetching

High

• Category: Supply Chain

Content

### 检查 Jenkins

```bash
curl -u devops:devsecops http://localhost:8080/api/json | python3 -m json.tool
```

---

• Confidence: 90% confidence
• Finding: Remote code is downloaded and executed. This bypasses code review and could introduce malicious code.

YARA rule 'backdoor_persistence': Backdoor persistence with malicious payloads (shell commands, SSH key injection, hidden root users) [malware]

High

• Category: YARA Match

Content

��建数据库 → 运行扫描 → 生成报告 → LLM 分析 → 输出清单
```

---

## 📦 安装

### 1. 安装 Skill

Skill 已位于：`~/.openclaw/workspace/skills/codeql-llm-scanner/`

### 2. 安装 CodeQL

```bash
# 下载
wget https://github.com/github/codeql-cli-binaries/releases/latest/download/codeql-linux64.zip

# 解压
unzip codeql-linux64.zip -d /opt/codeql

# 添加到 PATH
echo 'export PATH=/opt/codeql/codeql:$PATH' >> ~/.bashrc
source ~/.bashrc

# 验证
codeql --version
```

---

## 🚀 使用方法

### 方法 1: 在对话中直接使用（推荐）

在 OpenClaw 对话中直接说：

```
扫描 /root/devsecops-python-web 的安全漏洞
```

或

```
用 CodeQL 分析这个项目的安全问题，生成验证清单
```

### 方法 2: 使用命令行脚本

```bash
cd ~/.openclaw/workspace/skills/codeql-llm-scanner

# 扫描当前目录
./run.sh /path/to/project

# 扫描靶机
./run.sh /root/devsecops-python-web ./scan-output
```

### 方法 3: 使用 Pyth

• Confidence: 75% confidence
• Finding: YARA rule matched a known malware signature (reverse shell, backdoor, ransomware, C2 framework, or info stealer).

YARA rule 'backdoor_persistence': Backdoor persistence with malicious payloads (shell commands, SSH key injection, hidden root users) [malware]

High

• Category: YARA Match

Content

��建数据库 → 运行扫描 → 生成报告 → LLM 分析 → 输出清单
```

---

## 📦 安装

### 1. 安装 Skill

Skill 已位于：`~/.openclaw/workspace/skills/codeql-llm-scanner/`

### 2. 安装 CodeQL

```bash
# 下载
wget https://github.com/github/codeql-cli-binaries/releases/latest/download/codeql-linux64.zip

# 解压
unzip codeql-linux64.zip -d /opt/codeql

# 添加到 PATH
echo 'export PATH=/opt/codeql/codeql:$PATH' >> ~/.bashrc
source ~/.bashrc

# 验证
codeql --version
```

---

## 🚀 使用方法

### 方法 1: 在对话中直接使用（推荐）

在 OpenClaw 对话中直接说：

```
扫描 /root/devsecops-python-web 的安全漏洞
```

或

```
用 CodeQL 分析这个项目的安全问题，生成验证清单
```

### 方法 2: 使用命令行脚本

```bash
cd ~/.openclaw/workspace/skills/codeql-llm-scanner

# 扫描当前目录
./run.sh /path/to/project

# 扫描靶机
./run.sh /root/devsecops-python-web ./scan-output
```

### 方法 3: 使用 Pyth

• Confidence: 75% confidence
• Finding: YARA rule matched a known malware signature (reverse shell, backdoor, ransomware, C2 framework, or info stealer).

Credential Access

High

• Category: Privilege Escalation

Content

利用：__import__('os').system('id')
   
3. 命令注入 - vulnerable_app.py:88
   利用：; cat /etc/passwd
```

---

• Confidence: 94% confidence
• Finding: The command injection example includes a payload to read /etc/passwd, demonstrating unauthorized access to sensitive system data. Even though it is illustrative, it provides a concrete post-exploitation action that can be reused directly and signals credential/system information access.

Intent-Code Divergence

High

• Confidence: 97% confidence
• Finding: The document claims zero data collection, local-only processing, and no remote transmission, yet elsewhere instructs users to download tooling from GitHub and upload SARIF results through GitHub Actions. This is a materially misleading security/privacy claim that can cause users to expose scan artifacts or metadata under false assumptions.

Static analysis

No suspicious patterns detected.