Cyberlop activity feed: what it records and how to use it for audits

The Cyberlop activity feed records who did what in your workspace, from sign-ins and scan starts to triage decisions, role changes and support sessions. Open Activity in the sidebar, search by actor, action or entity, and read each entry as "Action · Entity" with its detail chips, time and short ID. This guide shows how to read it and how to use it for audits.

What is the activity feed?

The activity feed is the page at Activity that lists recent actions across your scope, newest first. Its subtitle reads "Recent actions across your scope — scans, triage, profile and target changes." It is the place to answer "who changed this, and when?" without asking around.

It is read-only. You cannot edit or delete an entry. Each entry is one event, written by a person, by a support engineer, or by the system itself.

Why does an audit trail matter?

Logging gaps are a known weakness. OWASP lists Security Logging and Monitoring Failures as A09 in its Top 10 for 2021, and says auditable events "such as logins, failed logins, and high-value transactions" are often not logged. Across the data it analysed, the category showed a maximum incidence rate of 19.23% and an average of 6.51%, with 53,615 total occurrences (OWASP Top 10:2021, A09).

Stolen credentials make the record more valuable. Verizon's 2025 Data Breach Investigations Report, which analysed over 22,000 security incidents including 12,195 confirmed data breaches, lists credential abuse (22%) as a leading initial attack vector and says third-party involvement in breaches doubled to 30% (Verizon, 2025). A feed that shows logins, role changes and support access helps you spot both, including credential stuffing follow-ups and any insider threat signs. See audit log and logging and monitoring for the plain-English basics.

What does the activity feed record?

The feed records the actions below, as captured from the live app. Each row is an "Action · Entity" pair with the detail chips that explain it.

Events and their detail chips

Secret values are never written to the feed. The credential entries record that a token was set, not what it was. Secrets in Cyberlop are encrypted and never shown again after saving (see Git access and AI provider settings).

What does one entry look like?

Every entry has the same four parts, which makes scanning fast.

• Actor at the left: a user's email, a support person shown as "name · email", or a system chip for automatic actions.
• Title: "Action · Entity", such as "Triage · Issue".
• Detail chips: key: value pairs, such as Trigger: manual or Severity: high.
• Footer: the timestamp and the first eight characters of the entity ID.

The short ID is how you tie two entries to one object. A "Start · Scan" and a later "Cancel · Scan" for the same scan end in the same eight characters. The captured screens did not show which timezone the timestamps use, so check against a known event the first time. The organisation timezone in Settings → Organization is documented for schedules only.

Who can see the activity feed?

What you see depends on your role. According to Cyberlop's security page, the feed has three visibility tiers: organisation-wide for administrators, team-scoped for leads, and own-actions-only for everyone else. The API reference says the same: the activity feed is "visibility tiered by role".

The permission keys behind this appear in a custom role seen in the app: activity:read, activity:read_team, activity:read_all and audit:read. A role holds the keys that suit it, so a developer role does not need the organisation-wide view. Admins set this up in Administration, which this guide does not cover (see API tokens and permissions).

Check what your own view shows

If an event you expect is missing, you may simply be on a narrower tier. Ask an administrator to look at the same time window before assuming it was not recorded. This is the first thing to rule out when two people describe the same day differently. Narrow access follows least privilege, which the tiers support by design.

How do you search the activity feed?

Use the search box at the top of Activity. It is labelled "Search by actor, action, or entity..." and matches those three things. The captured page showed search only, with no separate date filter or export button.

1. Click Activity in the sidebar.
2. Type an actor's email, an action such as Triage, or an entity such as Role into the search box.
3. Read the matching rows from newest to oldest.
4. Note the timestamp and short ID of each row you need.
5. Repeat with a second term to cross-check, for example the actor and then the target name.

Search examples that answer real questions

How do you use the feed for an audit?

For an audit, use the feed as evidence of control: access is granted deliberately, changes are attributable and support access has a stated reason. OWASP's logging guidance lists the events worth recording, including authentication successes and failures and "use of higher-risk functionality including user administration" (OWASP Logging Cheat Sheet). It also describes four attributes each event should carry: when, where, who and what. Cyberlop entries carry a timestamp, an entity, an actor and an action with detail chips.

An audit-review checklist

1. Define the window. Pick the period the auditor asked about.
2. Review access changes. Search User and Role. Confirm each Invite, Create and Update has a business reason and that custom roles hold only the permission keys they need (see RBAC).
3. Review support sessions. Every Session Start should show a ticket reason and an Until time, and a matching Session End.
4. Review credential changes. Check the AI provider and Git token entries against a change request.
5. Review triage decisions. Search Triage and confirm that False Positive or Accepted Risk calls were made by the right people (see triage findings).
6. Review scan and target deletions. Deleting a target removes its findings, so each Delete · Target needs an owner.
7. Record your evidence. Save the timestamp, actor and short ID of what you reviewed, then note the review date and the person who did it.

Evidence to keep

Keep a short log of what you checked rather than screenshots of the whole page. Screenshots can carry user emails and target names, so store them as carefully as you store the findings. A line such as "Role created, 14:05, short ID noted, approved in ticket" is enough for most reviews.

What the feed does not prove

The feed records actions taken in Cyberlop. It does not record what happened in your own systems, and the captured screens did not show whether it holds every possible event type. Treat it as one source beside your code host and identity provider logs, and see incident response for how logs feed a response. For wider guidance on log handling, NIST's Guide to Computer Security Log Management (SP 800-92) is the long-standing reference.

How long is activity kept, and can you export it?

The retention period is set per organisation. Settings → Organization has a Retention (days) field, and Cyberlop's security page says retention is configurable and that admins can delete scans, targets and data at any time. The captured screens did not say whether retention applies to the activity feed itself, so confirm with your administrator before promising an auditor a specific history. See account and organisation settings and log retention.

The page has no export button in the captured screens. For a copy outside the app, the API reference lists GET /api/activity (activity feed, visibility tiered by role, permission activity:read) and GET /api/audit (audit event log, scoped to the caller, permission audit:read). Both need a session or a bearer token that holds the permission. Read the API reference guide for authentication. What the downloaded data contains was not captured, so test with a small window first.

Activity feed versus other records in Cyberlop

Use the feed for people and changes, and the other pages for results. See the issues list and fixed and regressed issues.

Troubleshooting and common mistakes

Most "missing entry" problems come from scope, wording or timing.

Two habits prevent most trouble. First, search by the short ID once you have it, since it ties several rows to one object. Second, review the feed on a schedule, not only when something goes wrong. Watch for privilege creep as roles grow. Pair it with access reviews and separation of duties where your team is large enough.

Next step

With people and changes covered, move on to automation. Continue with CI/CD integration to start scans from your pipeline, and see how Cyberlop handles your data on the security page. Self-hosted scans are covered in self-hosted scan agents, and you can read how reporting works on the evidence page.