Perforce (Helix Core)

What it does

The Perforce card connects Safeguard to a Helix Core server (p4d). You add depot paths or streams, or leave the list empty to see every depot and stream the account can read. For each one you pick the whole path or one of its top-level folders. Safeguard syncs only that path at the newest submitted changelist into a temporary workspace, scans it for an SBOM and findings, and records the changelist number as the scan's commit. The temporary workspace is deleted when the scan ends. New changelists are picked up by polling (the default) or by a change-commit trigger you install. Find the card under Integrations on the Project/Product tab.

Fixes arrive as a patch you download and apply. If you give the connection write access and choose it, Safeguard can also shelve a fix in a pending changelist for you to review and submit. Safeguard never submits a changelist.

Public vs private

Perforce has only a Private connection. Every Helix Core command runs as a user, so Safeguard always needs a user name with a password or a ticket.

Supported auth methods

Perforce servers often use a self-signed ssl: key. Safeguard shows the fingerprint the server presented. Compare it with the one your administrator gets from p4 -p ssl:host:1666 trust -l (or from p4d -Gf on the server) and tick the box. Safeguard then trusts exactly that key (Perforce's p4 trust -i <fingerprint>, never trust -y).

Permissions required

Safeguard only reads, unless you turn on shelved fixes. Perforce has no token scopes: access is the server's protections table (p4 protect). Give the user the smallest access that works.

Least privilege: a dedicated user with read on the paths you scan, for example:

read user safeguard * //depot/main/...

The list on the server comes with read. Leave fixes as patch downloads, or add open only on the paths where you want shelved fixes.

Token types

Expiry: a ticket expires after the Timeout of the user's groups (12 hours by default). For a ticket that lasts, put the user in a group with a longer timeout, or use a password. When the ticket expires, scans fail with the ticket error below until you paste a new one. Passwords expire only if your server sets a password policy.

What we never need: write, admin, super or owner access, p4 protect or p4 triggers access for the connection's user, submitting changelists, or any depot you do not add.

Workspaces: each scan creates a temporary workspace and deletes it at the end. A shelved fix keeps its workspace (sg-fix-…) so that you can see the shelf; delete it with p4 client -d after you submit or discard the fix. An unlicensed Helix Core server allows only a few workspaces (20 when we tested r25.1, from p4 license -u), so on such a server keep fixes as patches.

Step-by-step setup

Create the user on your server

1. As a super user, create the user: p4 user -f safeguard, then set its password with p4 passwd safeguard.
2. Add a read line for the paths you scan to the protections table (p4 protect), for example read user safeguard * //depot/main/.... Add open lines only for shelved fixes.
3. For a ticket instead of a password, run as that user p4 -u safeguard login -a -p and copy the ticket it prints.
4. For an ssl: server, get the server's fingerprint with p4 -p ssl:perforce.example.com:1666 trust -l from a machine that already trusts it.

Or check it with the p4 command line

p4 -p ssl:perforce.example.com:1666 -u safeguard login
p4 -p ssl:perforce.example.com:1666 -u safeguard changes -m1 //depot/main/...

Connect it in Safeguard

1. Open Integrations and choose the Project/Product tab.
2. Click Connect on the Perforce (Helix Core) card.
3. Enter a Name and the Server (P4PORT), for example ssl:perforce.example.com:1666.
4. Put one depot path or stream per line in Depot paths or streams, or leave it empty to list everything the user can read.
5. Choose Sign in with: User name and password, or User name and ticket.
6. Choose how often to Check for new commits, and how to Deliver fixes as (a patch, or shelved in a pending changelist with write access).
7. Click Check access. If the server's ssl: key is not trusted yet, compare the fingerprint shown, tick This is my server's certificate, and the check runs again.
8. Click Next, pick each path's folder, and connect with the scan depth you want.

Webhooks and triggers

• On connect: each path you select is scanned once.

• Polling (default): Safeguard checks the newest submitted changelist of each scanned path every 15 minutes (5 minutes to 24 hours, or off) with p4 changes -m1 -s submitted, and rescans when it changed.

• Change-commit trigger: in the connection's edit dialog, Scan on commit > Set up commit hook gives you a trigger script and a credential file, safeguard-hook.conf. Save both on the server, for example in /p4/common/safeguard/. Make the script executable and keep the credential file readable only by the user p4d runs as (chmod 600). Then a super user adds a line to the triggers table (p4 triggers) with the path you scan:

  safeguard change-commit //depot/main/... "/p4/common/safeguard/safeguard-change-commit.sh %change% %user% %serverport%"

  The server needs curl, and the trigger needs to be able to run p4 describe. After each submit the trigger sends the changelist number, its user and the changed depot files to https://api.safeguard.sh/scm/api/v1/integrations/vcs-hooks/<connection id>, authenticated with the credential. Safeguard then rescans the projects whose path the changelist touched. The credential is shown once. Issue a new hook credential rotates it and Revoke stops deliveries. The trigger never blocks or changes a submit.

• Schedules: you can also rescan on a schedule from Integrations > Scheduled.

What we read and store

• Read: the files under each scanned path at the scanned changelist, and the changelist's number, user and date. For a fix, the original content of the files it changes.
• Stored: the SBOM, findings and project metadata, with the changelist number as the scan's commit. For fixes, the patch and the files it changes. The password or ticket is encrypted at rest and never shown again after you save it. Non-secret settings (server, pinned fingerprint, polling, fix delivery) are stored with the connection.
• Not stored: the synced files and the temporary workspace, which are deleted when the scan ends. Each session uses private ticket, trust and environment files that are removed afterwards, and reads no P4CONFIG file.
• No customer data from this integration is sent to third-party LLMs.

Troubleshooting

Rotation and disconnect

• Rotate: change the password (p4 passwd) or create a new ticket, then open the connection's edit dialog, enter it, click Check access and save. To rotate the hook credential, click Issue a new hook credential and replace safeguard-hook.conf on the server.
• Disconnect: delete the connection under Integrations. Then remove the user's lines from p4 protect (or delete the user with p4 user -d -f safeguard), remove the safeguard line from p4 triggers and the two files, and delete any sg-fix-… workspaces and shelves you don't need.

Vendor references

• p4 help login, p4 help protect, p4 help trust, p4 help triggers and p4 help shelve, checked 2026-10-16 against P4/LINUX26X86_64/2025.1.
• Helix Core Command-Line (P4) Reference. Not re-checked online on 2026-10-16; the command help above is the source.