EDA Spec2GDS

• Outcome: Review
• Latest audit: Sep 12, 2026 · 8:53 AM UTC
• Version: 1.0.1

Overview

This skill is a disclosed EDA workflow helper, but installation and dashboard defaults create review-worthy host-privilege and data-exposure risks.

Install or run this only in a disposable VM or dedicated EDA machine. Review the setup scripts before use, avoid permanent docker-group membership where possible, do not expose the dashboard outside localhost, pin Docker images by digest, and treat specs, RTL, logs, and GDS outputs as potentially sensitive.

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 (4)

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: scripts/install_ubuntu_24_mvp.sh:23
• Finding: Persistent Root-Equivalent Access Through Docker Service and Group Membership<![CDATA[ ## Vulnerability Details **File Location**: `scripts/install_ubuntu_24_mvp.sh:23-24`; equivalent behavior also appears in `scripts/bootstrap_eda_demo.sh:72-78` **Vulnerability Type**: Persistent service enablement and excessive privilege assignment **Risk Level**: High ### Vulnerable Code ```bash sudo systemctl enable --now docker sudo usermod -aG docker "$USER" ``` Equivalent bootstrap behavior: ```bash log "Enabling Docker service" run_privileged systemctl enable --now docker if [[ "$AS_ROOT" -eq 1 ]]; then NEED_NEWGRP=0 else if ! id -nG "$USER" | grep -qw docker; then log "Adding $USER to docker group" run_privileged usermod -aG docker "$USER" NEED_NEWGRP=1 else NEED_NEWGRP=0 fi fi ``` ### Technical Analysis The installation scripts both enable the Docker daemon immediately and configure it to start automatically on future boots. They also permanently add the invoking user to the `docker` group. Docker is a legitimate dependency for the OpenLane backend, but permanent Docker-group membership is effectively root-equivalent access on conventional Docker installations. A Docker-group member can start a privileged container, mount the host root filesystem, access host devices, or modify host files as root. This exceeds the minimum privilege necessary for a single EDA run. The service enablement is disclosed in `SKILL.md` and `references/SECURITY.md` and does not appear to be a covert backdoor. Nevertheless, it creates persistent system state that survives completion of the Skill and host restarts. ### Attack Path 1. A user runs either optional installation script. 2. The script enables the Docker service across reboots. 3. The script permanently adds the user to the `docker` group. 4. After group membership becomes active, any process running as that user can communicate with the Docker socket. 5. A malicious dependency, compromised agent process, or local attacker operating under that account starts a container that mo ...[truncated 754 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Do not add users permanently to the `docker` group by default. 2. Prefer rootless Docker or rootless Podman for OpenLane execution. 3. If system Docker is unavoidable, use narrowly scoped privileged wrappers rather than unrestricted Docker-socket access. 4. Start Docker only when required: ```bash sudo systemctl start docker ``` Do not invoke `systemctl enable` unless the user explicitly requests boot-time startup. 5. Require a separate, explicit confirmation before making persistent privilege changes. 6. Run the backend in a dedicated VM or isolated build host with no sensitive host data. 7. Provide rollback instructions and optionally an uninstall script: ```bash sudo gpasswd -d "$USER" docker sudo systemctl disable --now docker ``` 8. Avoid mounting the host Docker socket into other agent containers, because socket access preserves the same root-equivalent risk. 9. Add a preflight warning that clearly states that Docker-group membership is equivalent to administrative access. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/serve_multi_project_dashboard.py:27
• Finding: Unauthenticated Network Exposure of EDA Projects and Generated Artifacts<![CDATA[ ## Vulnerability Details **File Location**: `scripts/serve_multi_project_dashboard.py:27-29`; `scripts/serve_demo_artifacts.py:55-58` **Vulnerability Type**: Unrestricted network binding and excessive document root **Risk Level**: High ### Vulnerable Code From `scripts/serve_multi_project_dashboard.py`: ```python os.chdir(str(BASE)) server = ThreadingHTTPServer(('0.0.0.0', port), Handler) print(f'Serving multi-project dashboard on http://0.0.0.0:{port}/_dashboard/index.html') ``` From `scripts/serve_demo_artifacts.py`: ```python os.chdir(str(REPORTS)) server = ThreadingHTTPServer(('0.0.0.0', port), Handler) print(f'Serving {REPORTS} on http://0.0.0.0:{port}/') print(f'Open http://<server-ip>:{port}/index.html') ``` ### Technical Analysis Both HTTP servers bind to `0.0.0.0`, making them reachable through every configured network interface where firewall policy permits. Neither server implements authentication, authorization, transport encryption, or request-origin restrictions. The multi-project server changes its working directory to the complete `eda-runs` directory and uses `SimpleHTTPRequestHandler`. Consequently, its document root is not limited to generated dashboard files. Reachable clients may request raw specifications, normalized specifications, RTL, testbenches, logs, synthesis output, reports, and backend artifacts. The demo server has a narrower document root, but it still publishes report content to all network interfaces without access control. This implementation also conflicts with the mitigation documented in `references/SECURITY.md`, which recommends binding dashboards to localhost. ### Attack Path 1. A user starts either artifact server on a workstation, VM, CI host, or cloud instance. 2. The process listens on all network interfaces on port 8765 or 8766 by default. 3. A remote party on a reachable network discovers or predicts the listening port. 4. The remote party sends unauthenticated HTTP requests to the server. 5. Fo ...[truncated 836 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Bind to the loopback interface by default: ```python server = ThreadingHTTPServer(('127.0.0.1', port), Handler) ``` 2. Add an explicit `--host` option and require a clear warning or confirmation before accepting non-loopback addresses. 3. Serve only a dedicated export directory containing files intentionally selected for publication. 4. Do not use the complete `eda-runs` directory as the HTTP document root. 5. If remote access is required, place the server behind an authenticated TLS reverse proxy. 6. Add access controls appropriate to the deployment, such as short-lived bearer tokens or mutually authenticated TLS. 7. Apply a restrictive firewall rule so the port is unavailable outside the intended management network. 8. Avoid publishing logs or specifications by default; use an allowlist of generated dashboard assets and approved downloads. 9. Update documentation to match the secure default and explicitly identify which files become remotely accessible. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/run_synth.sh:14
• Finding: Yosys Command Injection Through Unvalidated Synthesis Parameters<![CDATA[ ## Vulnerability Details **File Location**: `scripts/run_synth.sh:14-23` **Vulnerability Type**: Command injection in a generated Yosys script **Risk Level**: High ### Vulnerable Code ```bash mkdir -p "$WORK_DIR" cat > "$WORK_DIR/synth.ys" <<EOF read_verilog $RTL_FILE hierarchy -check -top $TOP synth -top $TOP stat write_verilog $WORK_DIR/synth_output.v EOF yosys -s "$WORK_DIR/synth.ys" >"$WORK_DIR/synth.log" 2>&1 ``` ### Technical Analysis The script inserts `RTL_FILE`, `TOP`, and `WORK_DIR` directly into a Yosys command file without validating or safely encoding them. Although the shell variables are quoted when initially assigned and when Yosys is launched, shell quoting does not protect values after they are interpolated into the generated `synth.ys` program. An argument can contain newline characters or syntax meaningful to Yosys. A crafted top-module name or path can therefore terminate the intended command and add another Yosys command. Because Yosys supports commands that interact with the operating system, successful injection can lead to arbitrary command execution with the privileges of the user running the Skill. Ordinary Verilog module names do not require arbitrary control characters. An allowlist based on valid Verilog identifier syntax would prevent this injection while preserving legitimate use. ### Attack Path 1. An attacker controls or influences the top-module parameter, RTL path, or synthesis work-directory argument. 2. The attacker includes a newline followed by an additional Yosys command in the supplied value. 3. `run_synth.sh` writes the malicious value verbatim into `synth.ys`. 4. The script invokes `yosys -s synth.ys`. 5. Yosys parses the injected line as an independent command. 6. Any operating-system command launched through the injected Yosys instruction runs as the account executing the synthesis script. ### Impact Assessment Exploitation provides code execution under the Skill user's account. Depending on that ...[truncated 508 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Validate `TOP` using an allowlist for supported Verilog identifiers. For a conservative MVP: ```bash if [[ ! "$TOP" =~ ^[A-Za-z_][A-Za-z0-9_$]*$ ]]; then echo "Invalid top-module name" >&2 exit 1 fi ``` 2. Reject newline, carriage-return, NUL, and other control characters in every value inserted into a Yosys script. 3. Resolve paths before use and restrict them to an approved project root. 4. Use Yosys-compatible path quoting or escaping rather than placing raw paths into the command file. 5. Reject work directories containing characters that cannot be represented safely in Yosys syntax. 6. Where supported, pass values through a structured Yosys API or fixed wrapper rather than generating executable command text. 7. Add regression tests using spaces, quotes, semicolons, brackets, and embedded newlines in all three arguments. 8. Run synthesis in a sandbox without Docker-socket access, sensitive environment variables, or write access outside the project directory. ]]>

T08 · Insecure Dependencies

Warning

• Location: scripts/bootstrap_eda_demo.sh:86
• Finding: Unverified and Mutable Third-Party EDA Dependencies<![CDATA[ ## Vulnerability Details **File Location**: `scripts/bootstrap_eda_demo.sh:86-97`; related installation behavior appears in `scripts/install_ubuntu_24_mvp.sh:26-30` **Vulnerability Type**: Unverified package installation and mutable container image tag **Risk Level**: Medium ### Vulnerable Code From `scripts/bootstrap_eda_demo.sh`: ```bash log "Preparing OpenLane virtualenv" python3 -m venv "$HOME/.venvs/openlane" # shellcheck disable=SC1091 source "$HOME/.venvs/openlane/bin/activate" pip install --upgrade pip pip install "openlane==${OPENLANE_VERSION}" if [[ "$SKIP_OPENLANE_PULL" != "1" ]]; then log "Pulling OpenLane image: $OPENLANE_IMAGE" if [[ "$NEED_NEWGRP" == "1" ]]; then sg docker -c "docker pull $OPENLANE_IMAGE" else docker pull "$OPENLANE_IMAGE" fi fi ``` Default image and version configuration: ```bash OPENLANE_VERSION="${OPENLANE_VERSION:-2.3.10}" OPENLANE_IMAGE="${OPENLANE_IMAGE:-efabless/openlane:latest}" ``` From `scripts/install_ubuntu_24_mvp.sh`: ```bash python3 -m venv "$HOME/.venvs/openlane" # shellcheck disable=SC1091 source "$HOME/.venvs/openlane/bin/activate" pip install --upgrade pip pip install openlane==2.3.10 ``` ### Technical Analysis The OpenLane top-level Python package is version-pinned, but installation does not use a lock file, package hashes, or verified signatures. Its transitive dependency graph can therefore change or be resolved differently over time. The script also upgrades `pip` without pinning or integrity verification. The default Docker image uses the mutable `latest` tag. A future image associated with that tag may differ from the image reviewed when the Skill was audited. The bootstrap script additionally allows `OPENLANE_IMAGE` to select another image and immediately pulls it. These are conventional upstream repositories rather than demonstrated malicious sources. The vulnerability is the absence of reproducible integrity controls, which is particularly important because the resul ...[truncated 1252 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Pin the Docker image by immutable digest: ```bash docker pull efabless/openlane@sha256:<reviewed-digest> ``` 2. Maintain a reviewed requirements or constraints file that pins the complete Python dependency graph. 3. Install Python dependencies with verified hashes: ```bash pip install --require-hashes -r requirements.lock ``` 4. Pin the pip version instead of performing an unrestricted upgrade. 5. Record dependency versions and image digests in generated run metadata for reproducibility. 6. Verify container signatures where the selected registry supports signed images. 7. Restrict or remove the `OPENLANE_IMAGE` override in automated or privileged contexts; otherwise validate it against an explicit allowlist. 8. Run downloaded components inside a disposable VM or sandbox without access to sensitive host files. 9. Use a trusted internal package mirror or container registry for reviewed artifacts. 10. Periodically update pinned versions through a controlled review process rather than relying on mutable tags. ]]>

SkillSpector

Vulnerability Patterns

• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Tool Misuse: Tool Parameter Abuse, Chaining Abuse, Unsafe Defaults
• Rogue Agent: Self-Modification, Session Persistence

Findings (66)

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence
• Finding: The declared description presents a broad orchestration skill for running an open-source EDA flow from specification through GDS and for creating/iterating/auditing AgentSkills. This code chunk does not perform those workflow-driving tasks. It only reads existing project/run/report files under a fixed workspace path and generates a multi-project HTML dashboard plus per-project detail pages. While the dashboard summarizes outputs from an EDA flow and links to generated artifacts like GDS, that is only a monitoring/reporting function, not the declared primary capability of driving the flow end to end. Therefore the description materially overstates and misrepresents this code chunk’s behavior.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 95% confidence
• Finding: The declared description promises a broad workflow orchestration capability for AI-driven chip design, including turning specs into RTL/GDS and auditing AgentSkills. This code chunk does something much narrower and materially different: it hosts previously generated demo artifacts via a web server and refreshes summary files by invoking helper scripts. While report-summary generation is loosely related to EDA outputs, the primary behavior here is demo artifact serving over HTTP, with hardcoded paths to one example design. That network-serving capability and narrow purpose are not reflected in the declared description, so this is a meaningful description-behavior mismatch.

Docker Socket Access

High

• Category: Privilege Escalation

Content

```bash
# Run OpenClaw inside Docker container with Docker socket mounted
docker run -v /var/run/docker.sock:/var/run/docker.sock \
  -v ~/workspace:/workspace \
  your-openclaw-image
```

• Confidence: 99% confidence
• Finding: Mounting `/var/run/docker.sock` into a container gives code inside that container control over the host Docker daemon, which is effectively host-level access. In an AI-agent skill context, this is especially dangerous because any compromise or misuse inside the container can escape container isolation and manipulate the host.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

sudo apt-get remove --purge yosys iverilog verilator gtkwave klayout docker.io

# Remove Python virtualenv
rm -rf ~/.venvs/openlane

# Remove Docker images
docker rmi efabless/openlane:latest

• Confidence: 90% confidence
• Finding: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

sudo apt-get remove --purge yosys iverilog verilator gtkwave klayout docker.io

# Remove Python virtualenv
rm -rf ~/.venvs/openlane

# Remove Docker images
docker rmi efabless/openlane:latest

• Confidence: 90% confidence
• Finding: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

sudo gpasswd -d $USER docker

# Remove skill files
rm -rf /path/to/eda-spec2gds
```

Note: Removing Docker group membership requires logout/login to take effect.

• Confidence: 90% confidence
• Finding: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

sudo gpasswd -d $USER docker

# Remove skill files
rm -rf /path/to/eda-spec2gds
```

Note: Removing Docker group membership requires logout/login to take effect.

• Confidence: 90% confidence
• Finding: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Anti-Refusal Statement

High

• Category: Anti-Refusal

Content

grouped_stages = render_grouped_stages(data.get('progress', {}))
    artifacts = ''.join(f'<li><code>{html.escape(x)}</code></li>' for x in data.get('artifacts', {}).get('artifacts', [])[:120]) or '<li>-</li>'
    flow_tail = '\n'.join(data.get('progress', {}).get('tails', {}).get('flow.log', [])) or 'No flow log yet.'
    warn_tail = '\n'.join(data.get('progress', {}).get('tails', {}).get('warning.log', [])) or 'No warning log yet.'
    diagnosis = data.get('diagnosis', {})
    compare = data.get('run_compare', {})
    baseline = compare.get('baseline') or {}

• Confidence: 80% confidence
• Finding: Skill instructs the agent to omit warnings, disclaimers, or ethical commentary. Stripping safety caveats hides risk from the user and is a common jailbreak preamble.

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 76% confidence
• Finding: The skill requests sensitive capabilities like sudo, Docker access, network use, and execution of shell-based scripts, but it does not declare a clear, enforceable tool scope such as allowed-tools for file and shell operations. That makes the operational boundary ambiguous and increases the chance an agent will execute broader commands than intended, especially when combined with installation and backend workflow steps.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

permissions:
      - sudo_access  # Required only for initial toolchain installation
      - docker_group  # Required for OpenLane backend runs
    install_script: scripts/install_ubuntu_24_mvp.sh  # Optional, requires sudo
  warnings:
    - This skill includes optional installation scripts that modify system state (apt packages, Docker group, pip virtualenvs)
    - Run installation scripts only in isolated environments (VM, container, or development machine)

• Confidence: 84% confidence
• Finding: The skill explicitly allows optional execution of a sudo-requiring installation script that modifies system packages, Python environments, and Docker group membership. Even though this is disclosed, sudo-capable scripted setup is inherently dangerous because it can alter host state, weaken isolation, and persist privileged access if run on a non-disposable system.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

# eda-spec2gds Skill

> **⚠️ Security Notice:** This skill includes optional system installation scripts (`scripts/install_ubuntu_24_mvp.sh`, `scripts/bootstrap_eda_demo.sh`) that require sudo access and modify system state. These scripts should only be run in isolated development environments (VM, container, or dedicated workstation), not production systems. Core skill operations (RTL generation, file management, report collection) are file-based and safe.

Execute a staged, artifact-first open-source EDA flow within the workspace. Prefer deterministic scripts for execution, keeping the agent focused on planning, generation, diagnosis, and iteration.

• Confidence: 81% confidence
• Finding: This section normalizes the use of sudo-backed setup scripts within the skill flow, which increases the likelihood that an agent or operator treats privileged execution as part of normal operation. In the context of a network-enabled, Docker-using EDA workflow, that expands the blast radius of any mistake or compromised dependency.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 93% confidence
• Finding: Pulling `efabless/openlane:latest` is unsafe because the `latest` tag is mutable and may resolve to different images over time, including a compromised or unexpected build. In a workflow that may be run with Docker privileges and network access, this creates a serious supply-chain risk and undermines reproducibility.

Session Persistence

Medium

• Category: Rogue Agent

Content

| Dashboard Serving | Local HTTP server on specified port | ✅ Safe |

These operations:
- Only read/write within the skill's project directories
- Do not require network access (except optional dashboard)
- Do not require elevated privileges
- Do not modify system configuration

• Confidence: 60% confidence
• Finding: Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

- Only read/write within the skill's project directories
- Do not require network access (except optional dashboard)
- Do not require elevated privileges
- Do not modify system configuration

---

• Confidence: 60% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

sudo apt-get install yosys iverilog verilator gtkwave klayout docker.io python3-pip python3-venv

# Enables Docker service
sudo systemctl enable --now docker

# Adds user to Docker group (privilege escalation potential)
sudo usermod -aG docker $USER

• Confidence: 94% confidence
• Finding: `sudo systemctl enable --now docker` enables and starts a persistent privileged service. In the context of this skill, that materially changes host state and broadens attack surface beyond simple file-based operations, especially because later guidance also involves Docker socket and group access.

Session Persistence

Medium

• Category: Rogue Agent

Content

sudo apt-get install yosys iverilog verilator gtkwave klayout docker.io python3-pip python3-venv

# Enables Docker service
sudo systemctl enable --now docker

# Adds user to Docker group (privilege escalation potential)
sudo usermod -aG docker $USER

• Confidence: 92% confidence
• Finding: `systemctl enable --now docker` introduces persistence by enabling a background service across reboots. While not malware-like persistence, it permanently changes host runtime behavior and expands exposure if the environment was expected to remain minimal or transient.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

sudo systemctl enable --now docker

# Adds user to Docker group (privilege escalation potential)
sudo usermod -aG docker $USER

# Creates Python virtual environment
python3 -m venv ~/.venvs/openlane

• Confidence: 99% confidence
• Finding: `sudo usermod -aG docker $USER` grants the user effective root-equivalent access on many systems because Docker can be used to mount the host filesystem or start privileged containers. The document does mention this, but the command still represents a real privilege-escalation risk if followed.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 75% confidence
• Finding: Docker image references without a specific tag (:latest is implicit) or digest (@sha256:...) can be silently replaced by a malicious image.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 93% confidence
• Finding: The documentation instructs users to pull `efabless/openlane:latest`, which is a mutable tag and can change over time without notice. If users follow this guidance, they may receive a different image than expected, creating a supply-chain and reproducibility risk for a workflow that already has elevated trust requirements.

Missing User Warnings

Medium

• Confidence: 91% confidence
• Finding: The plan explicitly includes a local HTTP server and exposing latest logs plus raw JSON, which can leak sensitive information such as filesystem paths, environment details, run metadata, proprietary design data, or credentials accidentally written to logs. In an EDA workflow, logs and generated artifacts often contain valuable IP and infrastructure details, so serving them without access controls, redaction, or user warnings creates a real information disclosure risk even if the server is only intended for local use.

Session Persistence

Medium

• Category: Rogue Agent

Content

Demonstrate that the skill can manage a staged EDA flow:

1. Create a run directory
2. Save raw specification
3. Normalize specification
4. Place RTL and testbench

• Confidence: 60% confidence
• Finding: Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.

Session Persistence

Medium

• Category: Rogue Agent

Content

1. Install apt packages for synthesis/simulation/runtime
2. Enable Docker service
3. Create Python virtualenv for OpenLane
4. Pull Docker image for OpenLane
5. Run `scripts/check_env.sh` to verify
6. Perform smoke test with `assets/examples/simple-fifo/`

• Confidence: 60% confidence
• Finding: Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

## APT Package Installation

```bash
sudo apt-get update
sudo apt-get install -y \
  yosys \
  iverilog \

• Confidence: 70% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

## APT Package Installation

```bash
sudo apt-get update
sudo apt-get install -y \
  yosys \
  iverilog \

• Confidence: 70% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

## APT Package Installation

```bash
sudo apt-get update
sudo apt-get install -y \
  yosys \
  iverilog \

• Confidence: 70% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Static analysis

No suspicious patterns detected.