Skip to main content

What's New

Release highlights for the CICADA IR incident response platform. Each release adds new detections, data source integrations, and UX improvements. Current version: 1.83.9.


1.83.9

Dependency modernization — full backend stack current, zero known vulnerabilities

  • A full dependency audit reports zero known vulnerabilities. The Python dependency stack bundled with the appliance was refreshed and re-scanned, with no outstanding advisories.
  • 52 backend packages brought to their latest compatible releases. Including the cryptography, PDF rendering and AI provider libraries — each verified against the test suite and a live application boot with no regressions. The published Software Bill of Materials (SBOM) has been refreshed to match.

1.83.8

Interactive entity relationship graph — plus a security patch sweep of Python dependencies

  • The entity relationship graph is now an interactive node-link map. On the Timeline → Entities tab, users, devices, applications and the relationships between them render as an explorable diagram with a stable hierarchical layout, pan and zoom, and verdict colour-coding. Toggle between the new Graph view and the existing List view, and right-click any node to assess it, add it to scope, or pivot to its related events.
  • Patched 11 known security advisories in bundled Python dependencies. Five packages — pyjwt, aiohttp, urllib3, starlette and idna — were upgraded to fixed releases. All were minor or patch upgrades, verified against the test suite and a live application boot with no regressions.

1.83.7

Graph engine — crash-safe persistence and clearer group/resource semantics

  • The relationship graph is always saved now. A regression in v1.83.6 meant that if blast-radius analysis hit an error, the entire entity relationship graph could be lost — not just the verdicts. The graph is now always saved, so you keep the relationship map even when blast-radius analysis can't finish.
  • Group nodes read as membership pivots, not accessible resources. A compromised user's group membership was being shown with a Technically Accessible verdict on the group node, which read as if the group itself were a resource that may have been accessed. The graph now describes it as a membership pivot and points to the Blast Radius report — which enumerates the resources actually reachable and which of them were accessed — as the authoritative accessible-vs-accessed view.

1.83.6

Graph engine — blast-radius verdicts now carry the evidence behind them

  • Verdicts now ship with their evidence. Blast-radius verdicts (Confirmed Compromised, Potentially Compromised, Observed Accessed) had been displaying without the supporting evidence behind them, so reports cited a classification with no underlying evidence to back it. Each verdict now carries the evidence that drove it, so you can trace exactly why an entity was classified the way it was.
  • No more contradictory coverage notes. When an attack-path endpoint was promoted to Observed Accessed, it could still display a stale "No audit logs available" note next to the new verdict. That note is now cleared, so the row reads consistently.
  • Cleaner entity records. Re-running analysis could create spurious placeholder entities for declared compromised-identity values that didn't match anything in the case, gradually cluttering the entity list. That no longer happens. Placeholder records left by earlier versions clear on a fresh per-investigation re-analysis.

1.83.5

Blast-radius verdict accuracy · machine-account compromised identities · one-node-per-host graph · attack-path endpoint flooring

  • Compromised machine accounts now register on the Case Narrative. When the declared compromised identities were machine / computer accounts (e.g. DOMAIN\HOST$), Case Narrative could show "0 Confirmed" on a genuinely compromised investigation. Those identities now map correctly to the host's node in the entity graph, so the blast radius marks it confirmed-compromised and propagates from there. User accounts were always handled correctly — machine accounts silently matched no node.
  • One host, one graph node. The same machine could previously appear two or three times in the entity graph (WORKGROUP\HOST$, HOST$, and host as separate nodes), splitting its edges and under-counting how far the blast radius reached. Device nodes are now canonicalised to a single form per host.
  • Attack-path endpoints flagged as accessed. Entities the engine reconstructs an attacker as having reached are now flagged "observed accessed" in the blast radius even when no direct relationship in the graph surfaced them — without ever downgrading a stronger verdict already assigned.
  • Frontend build tooling. Internal build and test dependencies were upgraded to stay aligned, resolving a long-standing dependency-resolution warning. No app-behaviour changes.

1.83.4

Six new IR playbook scenarios · branch-aware playbook surface · UI polish · LLM grounding fix

  • Six new incident-response playbook scenarios. Business Email Compromise, Data Breach, Insider Threat, Ransomware / Exfiltration, SaaS Compromise, and Supply-Chain Compromise. Each playbook is branch-aware — the runner walks the path your evidence supports rather than a single rail — and a new recommendation engine surfaces the best fit for an active investigation from the gallery.
  • Playbook surface redesigned. The linear wizard is replaced with a branch-aware view that shows progress along the path the analyst actually takes — with a progress tree, branch indicators, and step cards that surface the relevant investigation context at each step. Useful for the new scenarios above where decisions split the flow.
  • Last-playbook detach now clears the surface. Detaching the only attached playbook on an investigation used to leave the wizard fields stuck on screen because the abandoned instance remained selected after the list refresh. The page now drops cleanly back to the gallery.
  • Severity-pill alignment & Key Findings title-case. Severity pills on Investigation Timeline and the Incidents page now center their text — the colored dot was pushing the label off-center. Dashboard → Key Findings severity tags also render Title-cased ("Critical" / "High") instead of raw lowercase, and inherit the same centered-text fix.
  • LLM Assistant grounding for Type-3 logon IOCs. Previously an IOC mentioning one routable source IP could be pluralised in chat into a "6 distinct sources" lateral-movement narrative with hallucinated 127.0.0.1, ::1, fe80:: and adjacent /24 addresses. The chat context now surfaces the filtered set of routable source IPs per IOC so the assistant has ground truth, and it is prevented from inventing specific IPs, hostnames, or counts not in the evidence (mirroring the existing safeguard against inventing MITRE techniques).

1.83.3

MFA optional on first login · per-user MFA toggle · Timeline FP fix for DC machine accounts

  • MFA no longer forced on first login. v1.81.0 defaulted the org MFA policy to admin (every admin forced to enrol TOTP before reaching the UI) — too aggressive for evaluation. Default relaxed to none; admins opt in via Settings → Security → Auth Policy. Upgrade migration relaxes existing installs only when an admin hadn't explicitly chosen admin themselves.
  • Per-user MFA-required toggle on Settings → Users. Admin can require MFA on a specific account (contractor, privileged service-owner) without forcing the whole org. Auto-cleared once they complete enrolment.
  • Timeline FP fix — multi-source Type 3 logons on DC machine accounts. DCs naturally take Type 3 logons from many sources (LDAP, SMB, Kerberos), and the heuristic was firing Critical when the source set included loopback (127.0.0.1, ::1) or IPv6 link-local (fe80::) entries. New filter excludes those before counting; real lateral movement still fires.

1.83.2

Fresh-OVA hotfix — demo investigations now actually seed on first boot

v1.83.0 / v1.83.1's demo-investigation seeding was silently failing on fresh sealed appliances because some required storage wasn't yet initialised at startup time. Seeding ran too early, the resulting error was silently caught, and the demos never appeared.

Invisible in internal testing because pre-existing investigations had already initialised that storage. Affects every fresh customer appliance. Fixed so the demo data initialises its own storage defensively before seeding. Existing v1.83.0/v1.83.1 sealed appliances will pick up the demos automatically on next boot after upgrade.


1.83.1

Build hotfix — appliance build failure in the demo banner

v1.83.0's new demo banner carried leftover code from a deferred per-demo-message feature, which broke the appliance build. Removed the dead code; per-demo banner customisation can be re-added later.


1.83.0

Sample DEMO investigations + demo-mode overlay — customer-onboarding feature

Every CICADA appliance now ships with two seeded sample investigations so a freshly-deployed customer sees realistic data on every page without connecting real sources first. The demos illustrate the platform end-to-end — IOCs, timeline events, pre-baked threat-intel enrichment, configured-source badges, response actions, LLM Assistant. Customers can explore the full UI on every tier before bringing their own data.

  • DEMO: M365 BEC — alice.finance@northwind.local. Phished user → foreign-IP sign-in → OAuth consent grant → mailbox forward rule → bulk-recipient exfil. Sources: Entra ID, Defender for Cloud Apps, log-file parsing.
  • DEMO: AD Lateral Movement — Ransomware Precursor. Phishing payload → COMSVCS.DLL minidump → Kerberoasting → pass-the-hash → DCSync → admin logon to DC → vssadmin shadow-copy delete → C2 staging DNS. Sources: AD, Sysmon EVTX, PCAP, syslog. Hits the behavioural engine's Tier 1 + Tier 2 detections hard.
  • Demo-mode overlay. When the analyst clicks Enrich on a demo IOC, Test Connection on a demo source, or Approve + Execute on a demo response action, the backend returns simulated success without touching real credentials or adapters. The LLM Assistant returns a canned narrative per scenario. Zero impact on real investigations — the simulated behaviour applies only when an investigation is flagged as a demo; real investigations behave exactly as before.
  • Persistent yellow banner on every page within a demo investigation makes it visually clear the data is illustrative. Real investigations get no banner ever.
  • Don't count against Community quota. A Community VM with 3 real investigations and 2 demos reports quota 3/3, not 5/3. Demos never block creating a real investigation.
  • Deletable + delete sticks. Analysts can delete a demo via the standard delete button. Once deleted, it doesn't come back on the next boot — the seed-once choice is permanent. You can also opt out of demos entirely with a configuration option in the appliance environment.

1.82.6

No console login prompts — tty1–tty6 masked at install time

Closes the visual loop on the boot console: after the CICADA banner paints, the screen stays on the banner. No console login prompt appears on top, on any virtual terminal. Customer journey is web UI only; the console login prompt served no real-world flow on a production appliance (interactive system logins are disabled and the root account is locked).

Honest scope: UX polish. Not a security boundary — anyone with offline disk-mount access could re-enable console login. Real defense against disk-mount requires full-disk encryption (LUKS) with a passphrase that isn't stored on the appliance — tracked for v1.85+. The emergency-recovery [E] prompt at boot is unaffected and remains available at the console.


1.82.5

Post-recovery UX — banner repaints + optional [R] reboot prompt after the emergency-recovery menu exits

After quitting the emergency-recovery menu, the operator was dropped straight to the login prompt with the recovery-menu scrollback still on screen. v1.82.5 repaints the CICADA banner after the recovery session ends and offers a 10-second [R] reboot prompt — particularly handy after a password reset where you typically want a clean reboot before logging in. Any other key (or 10s timeout) falls through to the login prompt as before.


1.82.4

Emergency-recovery menu: every option was crashing on the first audit write

Hotfix following the v1.82.3 quiet-boot patch. v1.82.0 — v1.82.3 had a latent bug in the emergency-recovery menu's dual-channel audit logging that crashed every option (1-4) on the first audit-write call. So in practice the recovery menu was reachable via [E] but every selection failed before doing anything useful.

Root cause: the audit-logging path tried to start a nested asynchronous operation while one was already running, which the runtime refuses to allow. Fixed by reworking the audit path to run correctly within the existing async flow across all of its call sites. All four menu options now complete cleanly through both the happy path and every abort / no-target / error branch.


1.82.3

Quiet-boot config · CICADA banner is the last thing on the customer console

After the v1.82.2 fixes the emergency-recovery menu worked, but on a freshly-built customer appliance the CICADA banner painted first and was then pushed off-screen by service-start messages flowing to the console for the rest of boot. v1.82.3 silences those.

  • Boot-time logging is quieted so the kernel, device probing, and service-status broadcasts no longer print over the banner during boot.
  • A second, independent quiet-boot setting is applied as belt-and-braces for the case where the primary boot configuration is overridden by a hypervisor or provisioning path.
  • Applied across all supported appliance build and deployment paths.

Net effect: the CICADA logo, access URL, hostname, and [E] prompt are now the only things rendered to the console from boot through login. Backend is unchanged this release — version bump is for SBOM / release-notes / banner-version accuracy only.


1.82.2

Emergency-recovery [E] menu boot-crash hotfix · audit-log directory pre-created by installer

Two v1.82.0 bugs in the emergency-recovery [E] flow at the console, both surfaced on a fresh appliance build. The menu printed, but every option crashed with a permissions error before reaching its first data lookup.

  • The recovery tool now starts from the application directory. The console banner process started in a directory the service account couldn't write to, so resolving the data path tried to create a directory it had no access to and failed. The startup path now defensively switches to the application directory from both the tool itself and the banner launcher, closing it both ways.
  • The audit-log directory is now pre-created by all appliance build paths. The installers now create the audit-log directory and file with appropriately restricted ownership and permissions. The recovery tool no longer attempts to create it — a missing directory now indicates a misconfigured install rather than something to paper over.

Existing v1.82.0 / v1.82.1 appliances can either rebuild (clean) or upgrade in place to pick up the fix.


1.82.1

Activation → Current License seat-count accuracy · Enterprise tier default 5 · Admin Product Keys copy-to-clipboard over HTTP · Storefront seats fallback

Patch bundle following v1.82.0 — four issues surfaced in live use.

  • Activation → Current License now shows the right seat count. The license-info path was reading from a legacy license source which had no awareness of product-key activations, so the Activation panel always reported 1 seat regardless of how many seats the activated key carried. It now reads from the activated product key directly — seat count, expiry, and key prefix all reflect the signature-verified value embedded in your activated key.
  • Enterprise tier default corrected: 10 → 5 seats. The default seat counts across all components now agree on Community = 1, Professional = 3, Enterprise = 5, Premium = 10. Existing activated keys are unaffected — the seat count is signature-protected on the key itself, not derived from defaults — but new keys generated without an explicit seat override now land at the correct tier default.
  • Admin Product Keys page copy-to-clipboard works over HTTP. The modern clipboard API only works in a secure context (HTTPS or localhost), and the admin portal runs on plain HTTP for LAN-internal use, so the copy button silently failed on every click. It now detects this and falls back to a legacy copy method when needed.
  • Storefront seats-fallback bug. The admin key-generation API defaulted to 1 seat when callers omitted the seat field, silently demoting any tier to a single seat. The admin portal always sends an explicit value so it was unaffected; direct API callers and webhook integrations were the silent victims. It now falls back to the correct per-tier default when the request omits the field.

1.82.0

Console-only emergency recovery for sealed appliances · emergency-admin designation · pre-v1.81.3 compromised-identity backfill

Closes the “sealed-appliance lockout” gap from v1.81.1 without introducing any remote attack surface. Three changes, all bounded to console-or-startup paths.

  • Emergency-admin flag. A single user is now designated as the dedicated console-recovery target. Set automatically on the first admin created by the setup wizard; backfilled on upgrade to the oldest setup-wizard admin (fallback: oldest active admin). The designation cannot be deleted, demoted, or deactivated via the API regardless of how many other admins exist — the console-recovery menu is the only path to move or clear it.
  • Console-recovery menu. The boot banner on tty1 now offers a 10-second [E] prompt. Pressing E enters a four-option menu (each option gated by a verbatim typed confirmation phrase): reset emergency-admin password, designate a new emergency admin, disable all SSO providers, or clear the emergency-admin flag entirely (with a strong multi-line warning explaining that future password resets via the console will no longer be possible and recovery from a fully-lost SSO + admin password state would require hypervisor disk-mount). The recovery tool refuses to run without a console session, refuses to run as any account other than the dedicated service account, and writes every action to both the authentication audit log and a protected on-disk recovery log. Blast radius equals what physical hypervisor console access already implies — no new remote attack surface.
  • Pre-v1.81.3 compromised-identity backfill. v1.81.3 fixed the write path so newly-declared compromised identities are saved to both the in-memory investigation state and the canonical IOC store. Investigations created before v1.81.3 still only had the identity in the older state file. v1.82.0 adds a one-shot startup migration that walks every existing investigation and persists any missing identities so the Dashboard, Timeline, and reports surface them on upgrade.
  • Killed during security review. The storefront-issued recovery token flow that was on the original v1.82.0 plan was dropped — the threat model concluded it adds remote attack surface for essentially zero real-world use cases (customers with hypervisor console access can use the menu instead). Will only be revisited if a real customer specifically asks AND can articulate why the console-menu doesn't fit their workflow.

1.81.3

Known Compromised Accounts auto-promote actually reaches Dashboard, Timeline, and reports now

The “Known Compromised Accounts” field on the New Investigation modal saved correctly, but the auto-promotion to suspected IOCs was only writing to the legacy in-state IOC list. Post-v1.71 the Dashboard Key Findings, IOC Timeline, and reports all read from the canonical persisted IOC list — so declared identities never surfaced where the original v1.79.0 release notes claimed. A partial-migration bug from the v1.71 IOC-truthfulness pass. Fix: auto-promotion now writes to both the in-state list and the persisted list. Blast Radius / Attack Path / Client Exposure were unaffected by the bug since those read the in-state compromised-identities list directly — this release closes the gap on the persisted views.


1.81.2

Cleanup · Test Stub playbook removed · Pricing-page acronym fix

Small follow-up patch to v1.81.1. Two cleanups noticed in live use of the SSO release.

  • Test Stub playbook removed from the production gallery. The minimal two-step playbook used by the framework test suite was leaking into the customer-facing Playbooks page on first run. Removed from the production codebase entirely; the framework tests now register it inline.
  • Pricing-page acronyms. The Professional tier card no longer displays “Saml Sso” / “Oidc Sso”. SAML, OIDC, SSO, MFA, and TOTP now render correctly uppercased.

1.81.1

SAML 2.0 + OIDC SSO · JIT user provisioning · Sealed-appliance lockout guards

Picks up the SSO half of the v1.81 plan. SAML 2.0 and OpenID Connect ship together, both fully provider-agnostic — Entra ID, Okta, Google Workspace, JumpCloud, Auth0, Keycloak, and any standards-conformant IdP. JIT provisioning links existing local users by email or creates fresh ones with role mapped from an IdP claim. The companion frontend wires it up: admin CRUD in Settings → Security, per-row provider/MFA icons in Settings → Users, “Sign in with…” buttons on the login page.

  • OpenID Connect. Compatible with every IdP that exposes a standard discovery document at <issuer>/.well-known/openid-configuration. State + nonce cookies, IdP-mixup-attack-defensive aud validation, JWKS-verified ID token signatures.
  • SAML 2.0. SP-initiated AuthnRequest via HTTP-Redirect; signed Response via HTTP-POST binding. NameID format emailAddress by default. SP metadata XML served at /api/v1/auth/sso/<id>/metadata.xml — paste the URL into your IdP at setup time.
  • JIT user provisioning. First-time SSO sign-in either links to an existing local user by email match or creates a fresh user with role resolved from an IdP claim. Multi-group membership: highest-rank match wins. No match: configurable default role. Existing local admins keep their original role on link (mappings don't override).
  • Sealed-appliance lockout guards. Production CICADA VMs ship as a sealed appliance — no SSH, no SQLite recovery for customers. v1.81.1 hard-refuses any admin action that would leave zero admins able to sign in via local password, and warns when an SSO-linked user is being promoted to admin. JIT-provisioned users have a placeholder password no one knows, so they don't count as a recovery path. The platform always keeps a break-glass account.
  • Local password sign-in is always available. Adding SSO never removes the username/password form on the login page. The IdP can be unreachable, expired, or misconfigured; you can still sign in as long as a password-capable admin exists.
  • MFA force-enrol gate refresh fix. The v1.81.0 force-enrol policy could be dropped by a page refresh because the session-state endpoint wasn't re-reporting the policy. Fixed: the session is now re-evaluated on every validation and the enrolment gate stays active across refreshes.
  • Settings polish. Settings tabs no longer overflow horizontally with 8 tabs, no longer reserve a phantom vertical scrollbar gutter. The General → Save Settings button is back to the default size matching the rest of the app.

1.81.0

Local two-factor authentication · Append-only auth audit log · Admin-required by default, voluntary for other roles

A second factor lands on cicada-app's local authentication. Password-only sign-in has been the open finding from the 2026-04-27 independent security review since v1.70.1, and a hard-stop for procurement in regulated DFIR verticals. This release closes it. SAML 2.0 and OpenID Connect (Entra ID, Okta, Google Workspace) ship next on the same branch.

  • RFC 6238 TOTP enrolment. Compatible with every mainstream authenticator: 1Password, Authy, Google Authenticator, Microsoft Authenticator, Bitwarden, Duo, and any other client speaking the standard. Enrolment is a single trip through Settings → Security: scan the QR with the authenticator app, type the 6-digit code it shows back, save the 10 backup codes the app reveals once.
  • Keyed-HMAC secret storage. TOTP secrets are AES-GCM-sealed under a server-held key before they are persisted. An attacker reading the database directly gets ciphertext only. The enrol and verify paths fail closed if no key is configured — there is no plaintext-secret storage path.
  • Backup codes for break-glass recovery. Ten one-time codes per enrolment in a XXXX-YYYY format drawn from a Crockford-style alphabet (no 0/1/O/I ambiguity). Single-use, bcrypt-hashed, then the hash list is AES-GCM-sealed on top — closing the gap that 40-bit-per-code entropy would otherwise leave open against an offline GPU sweep. Admins can also force-clear a user's TOTP enrolment from Settings → Users as the last-resort recovery path.
  • Admin-required by default. The MFA policy ships set to require enrolment for admins — every admin must enrol on next sign-in. Other roles are voluntary. Admins can flip the policy to Required for admins and IR leads or Required for everyone from Settings → Security. Users in scope are routed straight into the enrolment modal after their next password sign-in, before they can navigate elsewhere.
  • Append-only auth audit log. A new append-only audit log records every login, MFA challenge, verify success/fail, enrol step, backup-code use, and policy change with the source IP and user-agent. Usernames are stored as truncated SHA-256 hashes so the support bundle (which is unauthenticated for lockout-recovery) does not leak the set of valid usernames. Admins read the log from Settings → Security with an event-type filter for compliance reviews. Replaces the file-only application logger as the queryable surface.
  • Tier placement. MFA is included in Community (free) — security primitives should never be paywalled. SSO (SAML 2.0 + OIDC) is wired into the Professional tier so 50-seat MSP customers can adopt it without an Enterprise upsell. The feature gates and schema columns for SSO land in v1.81.0; the route handlers + admin UI ship in v1.81.1+.

1.80.0

Forensic-grade evidence integrity · Keyed HMAC + append-only Merkle chain + cross-DB signed anchor · Truthful Verify toast

The Evidence Store Verify button now exercises three independent integrity layers instead of a bare SHA-256 over each stored file. The forensic claim a customer can make about their evidence store has moved from “this file isn't bit-rotted” to “single-row content tampering, insertion, deletion, reordering, and wholesale store replacement are all detectable to anyone without the integrity key.” The toast that motivated this work also stops lying — it now reads real counts from the server instead of fabricated placeholders.

  • Three integrity layers. Per-row content HMAC (a keyed hash of each stored file is recomputed and compared to the stored value — detects single-row content tampering). Append-only hash chain (each evidence record is threaded into a keyed tamper-evident hash chain — detects insertion, deletion, or reordering). Signed anchor in a separate store (the chain head is mirrored to a separate, independent store on every write so isolated replacement of the evidence store is detectable).
  • Fail closed when no HMAC key is configured. A dedicated 256-bit server-held secret is preferred, with a fallback to another server-held key (logged once on use). If no key is configured, both write and verify paths refuse rather than degrade to a bare SHA-256. Bare SHA-256 of data stored alongside its own hash is trivially forgeable; silent degradation would let a tampered DB pass verification.
  • Idempotent migration of pre-v1.80 evidence. On first access of an investigation with pre-v1.80 evidence, the store walks the records in chronological order, recomputes each one's keyed integrity hash, threads them into the chain, and writes the signed anchor to the separate store. The bootstrap trusts whatever was in the DB at migration time as the baseline (there's no way to retroactively make pre-key data tamper-evident), but it establishes truth going forward.
  • Verify toast tells the truth now. Success reads e.g. “8 of 8 files hash-verified · chain of 8 links intact · anchor matches.” Failure breaks out which of the three layers failed: a count of files whose content hash diverged, a count of chain breaks (insertion / deletion / reorder), and a separate anchor-disagreement signal. Empty investigations get an honest “No evidence files to verify yet — collect or upload evidence first” instead of the nonsense placeholder toast.
  • Threat model. An attacker with full write access to the evidence store but no integrity key cannot forge content hashes, chain links, or the chain-state signature — all three layers detect tampering. Wholesale replacement of the evidence store with a separately-built file is caught by the anchor disagreement. Not yet defended: an insider with simultaneous write access to both stores and the integrity key — closing that requires an external transparency-log witness, tracked for v1.81+. Coverage extension to normalized evidence, IOCs, correlated findings, and kill chains is also v1.81+ work; only raw evidence records are chained today.

1.79.12

Customer VM banner reliability · First-boot console always shows the correct IP · Hostname now operator-selectable at the build prompt

Five linked fixes for the customer first-boot console experience following field-test feedback on v1.79.11.

  • Banner DHCP poll bumped 30s → 45s. Covers slow-DHCP hypervisors (VLAN-tagged networks where the first DHCP request can take 30–40s) so the banner ships with the real IP rather than the “awaiting DHCP” placeholder.
  • 5-second read pause at the end of the banner script. Combined with new service-ordering so the banner runs before the login prompt is drawn, the banner is on screen for at least 5 seconds before the login prompt appears — long enough to read the access URL even when late boot messages flow past.
  • Build-time console banner replaced with a generic placeholder. v1.79.11 generated the banner during the build, which captured an internal build-time IP and shipped it to customers. Now a neutral “Booting CICADA IR…” placeholder ships in the image; the runtime service writes the real banner with the correct customer IP at first boot.
  • Customer VM hostname now operator-selectable at the build prompt. Default cicada-ir. Pre-fix the customer VM kept an internal default hostname carried over from the build environment, which leaked an internal name into the customer's console banner and shell prompt. Applied to both x86_64 and arm64 builds.

1.79.11

Customer .ova now opens in VMware Workstation · First-boot banner DHCP race fixed · Settings → Users gets Edit User

Two regression fixes for v1.79.10 customer images plus a small gap in user management closed.

  • Customer .ova imports cleanly into VMware Workstation. v1.79.10 was rejected with “Unsupported element ‘ElementName’” because the OVF's xmlns declarations had a one-character typo (wscl instead of wscim in the DMTF CIM schema URIs). VMware Workstation, ESXi, ovftool, and VirtualBox all now parse the file without complaint. Existing v1.79.10 .ova files are not affected by this fix — download v1.79.11 to get a working .ova.
  • Banner DHCP race on first boot. v1.79.10 customer images sometimes booted with the login screen stuck on “awaiting DHCP” because the banner generation raced DHCP and lost. The first-boot service now polls for an IP for up to 30 seconds before writing the banner, so the first-boot console shows the real access URL on every supported hypervisor.
  • Settings → Users now lets admins edit a user's display name, email, and role. Backend support has been there since the initial users feature; only the UI was missing. New pencil button on each row opens an Edit User modal. Username stays immutable.

1.79.10

Sidebar admin row redesign · Uniform status pills · CrowdStrike sign-up link removed

Three small UX fixes following the v1.79.9 sidebar restructure and the v1.79.8 status-pill centering work. No schema changes, no behaviour changes anywhere else.

  • Sidebar admin row redesign. Sign out moved into a kebab (⋮) dropdown so the analyst block reads as a single unit (with click-outside and Escape to close). Investigation name indented under the analyst name so it hangs from the same column. The three icon buttons — Cloud Access, Help, Theme — are now unified into 32×32 rounded pill backgrounds with consistent hover states. Resolves the v1.79.9 sidebar where Sign out floated far right and one icon was styled while two were bare.
  • Status pills drop redundant dot on six surfaces. Sources Offline Mode, Response action status, Reports generation status, Case Narrative “Pinned by analyst” / “Stale” tags, Timeline entity priority pills, and the Resume Investigation modal status pills now all have the colored dot removed. Same root cause as the v1.79.8 fix — the dot pushed text ~7px right of pill center, and the variant color already conveys state. SeverityBadge keeps its dot intentionally.
  • CrowdStrike Threat Intel sign-up link removed. CrowdStrike is enterprise-licensed and the URL pointed at a marketing page, so the generic “Get free API key →” affordance other TI providers use was misleading on that entry. The sign-up link is now an optional field in the provider config, so future enterprise-only providers can opt out cleanly.

1.79.9

Upload SHA-256 dedupe · Timeline UX polish · Sidebar investigation context · TLS upload modal · Uploaded Files KPI fix

Six fixes bundled. One small but real upload feature (content-addressable dedupe across all evidence routes), four Timeline / Sources UX issues that surfaced after the v1.79.8 audit, plus the TLS upload form which was never plumbed correctly on the frontend.

  • Upload dedupe across PCAP, log file, and Event Viewer. Every uploaded evidence file is now SHA-256 hashed on receipt and rejected with HTTP 409 (plus the existing record's metadata) if the same content has already been uploaded to the investigation. Stops the “refresh-and-retry” double-upload that re-processed the same .pcap / .log / .evtx and gives the UI enough context to surface “already uploaded as X at Y.” Per-investigation by design — analysts may legitimately re-upload the same evidence to another case.
  • Dashboard Uploaded Files KPI off-by-one fixed. v1.79.8 added EVTX uploads to the count, but log uploads were being counted twice because the log-file route mirrors entries into both metadata maps for the Sources page UI. Manifest now subtracts the overlap so 3 PCAPs + 1 auth log shows as 4, not 5.
  • Timeline IOC enrichment persists across refreshes. Threat-intel enrichment results were stored only in component state; refreshing the Timeline wiped the cache and analysts had to click Enrich again. The backend was already caching per-IOC enrichment — the frontend now hydrates from that cache lazily when an IOC card first expands.
  • Timeline IOC cards advertise their hidden actions. Pre-fix the only signal that an IOC card expanded into Enrich / Block / Isolate / Disable Account buttons was a bare chevron next to the title. Added a labelled “Show actions” link in the footer of every collapsed IOC card; tooltip lists the four actions.
  • Sidebar names the active investigation. A thin “Investigation” panel under the CICADA header now shows which case the analyst is inside. Renders only when an investigation is loaded; collapsed sidebar shows an icon with the name in the tooltip. Particularly useful when juggling multiple investigations.
  • Settings → TLS Certificate → Upload finally works. The Upload button used to open two hidden file pickers in sequence; dismissing either one exited silently with no toast and no error. Replaced with a modal that has both file inputs visible and labelled, plus a password field for encrypted PEMs (the backend supported encrypted keys since v1.79.7 but the frontend never exposed the field). Submit button stays disabled until both files are chosen.

1.79.8

UX polish — centered Sources status pills · Uploaded Files KPI counts EVTX · Pricing copy cleanup

Three small fixes in this release. Two cosmetic, one truthful-counting bug. No schema changes, no behaviour changes elsewhere.

  • Sources status pills now horizontally centered. The colored dot at the left edge of each Connected / Collecting / Queued / Error pill was pushing the label ~7 pixels right of the pill's visual center. The variant color (green / blue / yellow / red border + tint) already conveys status, so the dot was visual noise and a centering bug to boot. Dropped from the status pill component; severity badges and the Offline Mode warning still keep their dots.
  • Dashboard Uploaded Files KPI tile now counts Event Viewer uploads. Pre-v1.79.8 the tile counted PCAPs and log files but skipped EVTX/XML/CSV uploads — an investigation with three EVTX uploads showed zero on the tile. The manifest route now sums all three sources of manually-uploaded evidence so the count reflects reality.
  • Pricing page introductory-offer banner removed. The green callout above the tier grid duplicated the same offer that the Professional column already surfaces as a price footnote, so the page led with the same line twice in two visual styles. Top banner removed; Professional column footnote shortened from “Introductory offer — first 1000 downloads” to just “Introductory offer” — the count detail belongs in the offer terms, not on the price card.

1.79.7

Security hotfix — 5 Critical and 22 High audit findings closed across all four product repos

Comprehensive security review against OWASP Web Top 10 (2021), OWASP LLM Top 10 (2025), and CISA KEV produced 5 Critical and 22 High findings across cicada-app, cicada-admin, cicada-storefront, and cicada-vm-builder. This release closes all of them except two architectural items (DB encryption at rest, asymmetric license signing) which are tracked separately. No KEV/CVE hits — every pinned dependency is on a patched version.

  • cicada-admin: full authentication. Every admin API endpoint now requires admin auth (header or cookie). Pre-v1.79.7 the admin panel was completely unauthenticated; anyone with network access could mint product keys, revoke customer keys, override feature gates, and enumerate tenants. The public license-validation endpoint stays public (customer VMs phone-home with no shared secret) but is now per-IP rate limited at 20 req/min. CORS narrowed from a wildcard to an operator-configured allowlist.
  • cicada-vm-builder: TLS key permissions + reproducible builds. Customer VM TLS private key permissions tightened from world-readable to owner-only across all build paths. Dependency installs were pinned to a reproducible mode so frontend builds are deterministic across the same source. Build tooling is now verified to be removed so it never ships to production.
  • cicada-app: backend RBAC + crypto. Backup/Restore endpoints now require ADMIN; case-narrative writes (v1.79.4 ship) now require IR_LEAD; global-source connector mutations now require ADMIN. LLM provider API keys (Anthropic / OpenAI / Google) are now encrypted at rest in the application settings store, backwards-compatible with plaintext installs (lazy migration on next save). TLS upload accepts encrypted PEM keys; the on-disk key file is forced to owner-only permissions. Encryption master-key auto-generation is refused in production unless explicitly opted in.
  • cicada-app: exception handling + log hygiene. Global FastAPI exception handler returns generic 500s; full detail goes to logs only (no stack-trace leaks to the client). Per-IP login rate limit (10 / 15min) on top of the existing per-username exponential backoff. Failed-login + successful-login logs now record SHA-256 username hashes instead of plaintext (combined with the unauth support bundle, pre-v1.79.7 leaked the active username list).
  • cicada-app: LLM hardening. Indirect prompt-injection sanitiser applied to attacker-controlled evidence-derived strings (finding titles + narratives, IOC values, hostnames) before they reach the case-narrative AI-enhance prompt. AI-enhance now runs a sensitivity classifier on the prompt and refuses cloud-provider dispatch when HIGH/CRITICAL data is detected unless sending sensitive data is explicitly enabled for that provider.
  • cicada-storefront + frontend. Trial endpoint gains per-IP rate limit (5 / hour) defeating email-rotation farming. Activation page open-redirect surface closed: the storefront URL returned by the server is now allowlist-validated against cicada-ir.ai before the browser is redirected.

1.79.6

Re-run Collection actually re-collects · Source pills update in real time · Per-source collection_enabled toggle honoured · REPORTING-phase Re-run no longer silently no-ops

Three connected bugs around the Sources page Re-run Collection button surfaced when an analyst added Active Directory as a source after the initial Start Investigation completed and clicked Re-run Collection — the AD pill never flipped to “collecting” even though the backend was supposed to re-trigger every connected source.

  • Frontend stops sitting on stale source state. The collect-more handler showed a toast and exited; it never re-fetched the source list, and the 5s polling effect only activates if at least one source is already showing collecting/queued. Both handlers now refresh sources + investigation after the action so pills flip immediately and polling picks them up.
  • collection_enabled now honoured in the bulk Re-run loop — disabling collection on a source via the UI used to have no effect when an analyst clicked Re-run.
  • REPORTING-phase Re-run no longer silently no-ops. The button shows for both COMPLETE and REPORTING phases but the re-collection action was hard-coded to require COMPLETE; clicks during REPORTING reported not-started while the toast still said success. It now accepts both phases.
  • Toast reflects what actually happened — the wrapper used to discard the route response and re-fetch, so the analyst saw a success toast even when nothing started. New raw method threads started/message through; warning toast fires when started === false.

1.79.5

Community Edition tier limits enforced · Evidence Export, Backup/Restore, and Global Source Connectors moved to Professional · Pricing-page introductory offer

Five new feature gates land Professional-side. Community keeps every detection and analysis surface it had at v1.79.4 — only capacity-shaped capabilities now require a Professional license.

  • Five new feature gates. Evidence Export, Backup & Restore, Global Source Connectors, multiple concurrent investigations, and unlimited file uploads now all default to the Professional tier. The startup reconciliation that landed in v1.79.3 means existing installations upgrading to v1.79.5 see the right tiers applied automatically on the first startup with no manual intervention.
  • Community quotas. 2 lifetime investigations + 5 file uploads per investigation. Deletion reclaims a slot for both. The upload counter spans every type of uploaded evidence (PCAP captures, log files, and Windows event logs). Live usage is surfaced to the UI so buttons disable proactively, and the backend remains the source of truth, returning a clear error with actionable detail when a quota is reached.
  • Frontend disables. Evidence Store → Export button, Settings → Create Backup / Restore from Backup buttons, Settings → Source Connectors tab, Splash → Start New Investigation button, and the upload-type picks in the Sources → Add Source dialog all gate behind their respective tier checks. The Sources page renders a usage banner at the top that flips to a warning at the cap.
  • Pricing page introductory offer. A green banner above the tier grid plus a green caption under the Professional card's $399 price both spell out the “first 1000 downloads” offer. Pure copy for v1.79.5 — no auto-flip when the count hits 1000; that's a separate feature for later.

1.79.4

Case Narrative rewritten as a sectioned auto-generated investigation overview · Entity graph moves to a new Entities tab on the Timeline page

The standalone Case Narrative page used to be a recommended-actions card plus the entity graph. Useful, but it lived in the wrong place — analysts who wanted entity context on a specific timestamp had to bounce between Timeline and Case Narrative — and the page didn't actually narrate anything. This release reshapes both surfaces.

  • Nine deterministic sections, derived from current state on every fetch. Investigation Summary, Initial Discovery, Timeline of Events, Analysis, Evidence Collected, Actions Taken, Next Steps, Impact Assessment, Recommendations. Each section is a pure function of the snapshot the page loads (the investigation's current state, its collected evidence, and the response actions taken), so the document is always current with no scheduled-rebuild cadence to maintain.
  • Three sections (Initial Discovery, Analysis, Recommendations) are AI-enhanceable. A per-section dropdown lists every configured local model (Ollama / LM Studio / llama.cpp / litellm / custom OpenAI-compatible — probed at request time) plus every cloud provider you have explicitly enabled for cloud inference (Anthropic / OpenAI / Google). Pick one, click AI-enhance, and the section is regenerated against the deterministic baseline. Re-run with a different model whenever you want; output overwrites the cache. 800-token cap per call.
  • Stale-flag-with-banner. When the investigation moves between phases, cached AI sections get a Stale badge and the page shows a yellow banner (“New evidence has landed since the AI sections were last generated”) with a one-click button to regenerate every stale section against your selected model. Deterministic sections always rebuild on load and never carry a stale flag. Analyst-pinned sections are never marked stale — we don't invalidate work the analyst chose to keep.
  • Every section is editable in-place. Click Edit, type your override, save — the section becomes “Pinned by analyst” and stops auto-updating. Click “Revert to auto” to drop the override and let it live-derive again. Last-modified-by is captured from the analyst's auth context for attribution.
  • Entity graph moved to a new Entities tab on the Timeline page, immediately right of Evidence Events. Same components, same right-click flow, same response-action quick-create. Right-click → Show events on an entity stays on the Timeline page (tab swap) instead of cross-page navigating.

1.79.3

Cloud LLM “Not Purchased” on paid tiers fixed · Threat Intelligence providers stop appearing to vanish on direct navigation

Two related backend / frontend bugs that customers hit on freshly-activated Professional and Enterprise keys.

  • Cloud LLMs no longer show “Not Purchased” on paid tiers. Each feature's tier was recorded once on first startup and never resynced when the built-in tier assignments changed between releases. Cloud LLMs moved Premium → Free in v1.76 but the stored value still said Premium, so the gate rejected them on every installation that booted before that release. Startup now reconciles every feature against the current built-in tier assignments idempotently — eight features (cloud LLMs, syslog / DNS / DHCP / web log parsing, and automated response) corrected to the Free tier on first startup of v1.79.3.
  • Threat Intelligence providers stop appearing to vanish when the page is reached via direct URL (bookmark, refresh, or coming back from the “Get free API key” abuse.ch link). The Settings page had two disagreeing sources of “which investigation am I in” — the loader read the in-memory investigation store, often not yet populated on direct navigation; the empty-state UI read the URL. Result was a Threat Intel tab with zero providers even though the per-investigation file on disk was fully populated. Both call sites now read a single URL-first value.

1.79.2

Multi-cloud LLM picker · Stop button · investigation-id passthrough · v2 product keys with embedded seats · pricing label fix

Five fixes accumulated since v1.79.1, bundled into a single patch because the customer-VM rebuild needs them in one image anyway.

  • LLM Assistant — pick the cloud provider.Configuring more than one cloud LLM (Anthropic + OpenAI + Google) used to be confusing because the Cloud toggle silently always used the first in a hardcoded priority order. Now the Cloud button opens a popover listing each configured provider when two or more are enabled, with the active one checkmarked. The backend honours an explicit provider name in the chat request and falls back gracefully (with a warning toast) if the pinned provider becomes unavailable.
  • LLM Assistant — Stop button. The input area now swaps Send ↔ Stop while the assistant is responding, so analysts can cancel slow local-LLM inference (Ollama can take 60-90s on long answers) without waiting out the 120-second timeout. The cancelled prompt stays in the thread — no error toast.
  • Threat Intelligence providers stop “disappearing”.Six places in the LLM Assistant and the Tier-Gate upgrade screen were navigating to the Settings page without preserving the active investigation id. Switching to the Threat Intelligence tab in that stripped state showed the empty “Open an investigation to configure” panel. All six paths now thread the id.
  • Product keys carry the seat count. Previously, installations auto-registering an externally-issued key were limited to a single seat for every tier — so even Enterprise customers were stuck at 1 user and saw the wrong “Upgrade to Professional” copy at the seat-limit gate. The new v2 key format embeds the seat count in the tamper-protected payload, so installations extract the seat count fully offline. The Seats dropdown when issuing a key now flows through to the issued key; legacy v1 keys still validate using per-tier defaults (Free=1, Professional=3, Enterprise=10). A one-shot migration corrects already-redeemed Professional/Enterprise records that were stuck at a single seat — only adjusts upward, never reduces.
  • Pricing label. The Professional tier card used to read “$399 USD / month”, which was wrong — it's an annual subscription. Now reads “USD / year”.

1.79.1

Audit close-out — IOC auto-promotion + source-name canonicalisation

Closes the two deferred findings from yesterday's Professional-tier audit. Verified end-to-end on the test VM — the Executive Summary report on a heavily-attacked test investigation went from “0 confirmed IOCs / Severity LOW — may be precautionary” (v1.78.1) to “51 confirmed IOCs / Severity CRITICAL (Confirmed)” (v1.79.1) on the same underlying evidence.

  • IOC auto-promotion that actually fires. IOCs the behavioural engine never produced a score for (extractor-classified critical patterns from EVTX uploads that the behavioural engine had not scored) used to sit in the suspected bucket forever. New conservative promotion rules run as a post-step after the engine: severity=critical with MITRE attribution and repetition, OR reputation_level=malicious, OR threat_score ≥ 0.7 with severity critical/high. On the test investigation, 51/51 critical IOCs (DCSync, LSASS dumps, log clearing, SID-history injection, DSRM password change) auto-promoted on the first run. Each gets a synthesized explanation of which rule fired.
  • Source-name canonicalisation. Same provider used to land under multiple labels in evidence (Title-Case variants from seeded demo data, path-style labels, and legacy provider aliases). Filters and source-count rollups silently broke; the Executive Summary's “Data Sources: 1” was a downstream symptom. New normaliser at every chokepoint write site maps to canonical adapter names; idempotent migration helper rewrites existing records on the next analysis run. Upload-derived event-log and log-file source labels pass through unchanged.
  • Reports route per-investigation evidence store. Report rendering now reads from the evidence store scoped to the specific investigation instead of a shared store. Same per-investigation fix that v1.79.0 applied to data collection. On the test investigation, Total Events Analyzed corrected from 2,000 to 97,865 and Data Sources from 1 to 498.

With this release, all 13 findings from the Professional-tier audit are now either landed or documented as operational items. Enterprise-tier audit can proceed.


1.79.0

Professional-tier truthfulness pass — reports reflect engine output, UCG block-IP UX corrected

A focused remediation release that lands the high-priority fixes from a Professional-tier audit completed earlier today. Headline: the Executive Summary report could rate an investigation as “LOW — may be precautionary” while the engine had identified 25 attack-paths, 20 incidents, and 51 critical-severity behavioural IOCs. After this release, reports surface what the engine has actually found.

  • MITRE Mapping reports populated correctly. Reporting previously read MITRE technique data from a legacy field on IOCs whose canonical location had changed back in v1.71. Both data collection and the report generator now read the canonical field first (with legacy fields as fallbacks), and additionally pull techniques from the investigation's correlated findings and kill chains. On richly-attacked datasets, MITRE Mapping went from rendering “0 techniques, 0 tactics, 0 attack chain” to surfacing the full coverage the engine had identified.
  • Executive Summary now factors in engine findings. IOC counts now come from the canonical IOC store rather than a secondary in-state copy (which had been observed to drift by 600+ entries on a single investigation). Severity scoring now factors in critical-severity IOCs in suspected, behavioural incidents, attack-paths, and critical correlated findings — severity still caps at HIGH (Suspected) without confirmed IOCs and confirmed exfil, but the engine can finally surface “this is bad” when behavioural signals are dense.
  • Ubiquiti UCG description corrected and badged. The source picker had advertised UCG as supporting “firewall log collection and IP blocking response actions” — but the adapter has always failed log collection because the UniFi REST API does not expose firewall logs. UCG is response-only by design. Description rewritten, new “Response only” badge renders on the source card so customers see the constraint up front.
  • UCG block-IP no longer claims the IP is blocked when it isn't. The UniFi ZBF firewall API stages a created policy in pending state until an admin clicks “Apply Changes” in the web UI. Pre-v1.79 the action reported success with the message “Blocked IP {ip}…” regardless. During an incident, an analyst would trust the success state when the attacker IP could still be communicating freely. Fixed: best-effort attempts the v2 firewall apply endpoint; when apply isn't confirmed the message reads “BLOCK STAGED — NOT yet active” with a prominent yellow banner on the action card so it can't be missed.
  • Case Narrative + Blast Radius now work on engine-only output. Blast-radius traversal needs seed entities (compromised identities). The only source had been analyst-declared compromised_identities; on richly-attacked investigations where the analyst hadn't reviewed yet, every entity stayed at an unknown verdict and the Case Narrative page rendered “0 confirmed compromised entities” on data full of credential-theft / privilege-escalation chains. Now the compromised-entity seeds back-fill automatically from the originating entities of detected attack paths and the primary actors of high-severity incidents, so the verdict assessment runs even without manual declarations.
  • Reports table flags stale reports. Reports stamp the engine version at generation time; the page now compares that stamp against the running app version and renders a yellow “Stale” badge when major.minor diverges by ≥1 minor. Patch-level differences are ignored. An analyst returning to a report generated weeks earlier sees at a glance that engine improvements may have changed what the numbers mean.
  • Auto-promote critical-severity IOCs in reports. IOCs rated critical severity with a high threat score now auto-promote to “confirmed” in the report's IOC summary (report-time only — does not mutate canonical state). A partial address of a deferred audit finding around IOC promotion threshold calibration; full calibration against real-world data is on the next-cycle list.

The full audit doc, including the deferred findings (source-name normalisation, IOC threshold calibration, declared-vs-shipped report types) and the rationale for that scoping, is maintained in our internal documentation.


1.78.1

Community-tier log sources verified end-to-end · capability metadata aligned

A small follow-up to v1.78.0's tier reshuffle. The four log-based evidence sources that moved to Community — syslog, DNS log parsing, DHCP log parsing, and web access log parsing — were each exercised end-to-end on the test VM through the real collection → evidence store → IOC table → timeline pipeline. Result: every source ingests, normalises, and surfaces correctly.

  • Verified end-to-end. Each source was driven through the real collection pipeline with sample logs. Events land in the normalised Evidence Store, IOCs land in the canonical IOC list, and the Timeline surfaces Suspected IOC and Web Attack security-alert cards across all four source-categories.
  • Cross-source IOC dedup confirmed. An attacker IP observed in both syslog and web access logs surfaces once in the IOC list, attributed to both source types — the dedup key is the IOC value, not the discovering source.
  • DHCP behaviour intentionally different. DHCP logs contribute internal IPs and MACs to the investigation scope for entity correlation rather than producing direct IOCs — matching the parser's stated capability (“device-IP-MAC correlation”).
  • Capability metadata aligned. The four parsers' internal minimum-tier declarations were still “professional” (left over from before the v1.78.0 reshuffle). Now all read “free”, matching the feature gate, tier preset, and tier-config layers. No customer-visible change — runtime gating always read from the feature definitions, not the adapter metadata.
  • Two security audits filed in parallel. An engine review and a separate security assessment, both dated 2026-05-04, are kept in our internal documentation.

1.78.0

Community Edition gets log-based evidence + Automated Response · Pricing restructure · Trust & SBOM section

A coherent product-positioning change. The previous tier split made Community feel like a demo; everything log-based now lives in the free tier so analysts can run a real investigation on real evidence without needing a Professional key.

  • Tier reshuffle. Moved into Community: syslog, DNS / DHCP / web log parsing, and Automated Response. Professional now leads with CrowdStrike and the analyst-workflow surfaces (Incidents, Playbooks, Case Narrative, Reporting, Blast Radius). Existing Professional / Enterprise keys keep all their features — nothing has been taken away.
  • Dashboard: Uploaded Files KPI tile between Configured Sources and Events Ingested. Counts PCAP + log files manually uploaded; click navigates to Sources.
  • Cloud LLM toggle now renders green-on-active with explicit copy: “Permit sending non-sensitive evidence to Cloud LLM: OpenAI GPT” plus a follow-up clarifying that PII and credentials stay on the VM unless the second consent toggle is also flipped.
  • Help docs Getting Started uses the actual button labels (Start Collection / Analyze Uploaded Evidence), not the long-removed Run Investigation wording.
  • Pricing page restructure. Community card renders three named subgroups (Capabilities · Configurable sources · Log-based evidence sources) instead of one flat list. Professional priced at $399 USD / month with seats line “1 to 3 users” (CTA still Contact Us). CrowdStrike is the first item under “Everything in Community, plus:”.
  • Landing page: Trust & transparency section. Six trust pillars covering SBOM publishing, data residency, cloud LLM safeguards, independent expert review, coordinated vulnerability disclosure, and an honest acknowledgement of what we're still earning (no SOC 2 / ISO 27001 yet — we'd rather lead with what we publish than with claims we can't substantiate).

1.77.13

Timeline IOC details: “Engine assessment” → “Why this severity”, collapsed by default, plain-English reasoning

The Timeline's per-IOC details panel exposes the behavioural engine's reasoning. That information is genuinely valuable — auditors and regulators reject opaque “AI says malicious” verdicts, and analysts need to knowwhy a flag fired before responding. But three weaknesses in the previous presentation diluted the value: the section was labelled with engine internals (the “Engine assessment” label), it was unconditionally expanded so it pushed actionable data below the fold, and the prose leaked engineer language (raw internal scores and threshold values).

  • Renamed the internal “Engine assessment” label to Why this severity. Analyst-facing label for analyst-facing content.
  • Collapsed by default. The summary line is the verdict in one sentence (e.g. “Confirmed — corroborated by 3 signals across 3 signal types (behavioural score 92%).”); click expands the rest of the categorizer reason plus Matched Patterns + Evidence Chain together, so the trio reads as one reasoning cluster instead of three separate sections.
  • Categorizer reason strings rewritten in plain English. Internal threshold names were replaced with prose: “Score 42% — needs ≥60% to auto-confirm”, “Only 2 corroborating signals — needs at least 3”, “Signals all came from 1 source — needs corroboration from at least 2 different signal types.”
  • Information loss: zero. Surface area shrank, density dropped, scannability climbed.

1.77.12

Threat Intelligence enrichment: abuse.ch 403s fixed + Shodan 404 no longer shows as “Failed”

Two enrichment-pipeline fixes for the most common false-positive failure modes analysts hit on the IOC enrichment job.

  • URLhaus / ThreatFox / MalwareBazaar 403 fixed. abuse.ch hosts all three behind Cloudflare. Cloudflare's bot-detection rejects the default HTTP-client User-Agent with HTTP 403 even when the Auth-Key header is present and valid — analysts saw Failed: 403 Forbidden for every IOC routed through these providers despite confirmed-correct API keys. Every TI request now sends a CICADA-IR/<version> (+https://cicada-ir.ai) User-Agent. Side benefit: identifiable traffic at the upstream end, so abuse.ch / Shodan / VirusTotal can attribute and rate-limit per-platform instead of treating us as anonymous Python.
  • Shodan 404 — was a “Failed”, should be “no data”. Shodan returns 404 whenever it has no data on an IP — common for private RFC1918, freshly allocated, or short-lived cloud-workload IPs. The old behaviour surfaced this as a real failure, polluting enrichment status with what is in fact a perfectly successful query that returned an empty result set. Now mapped to a clean “no data” enrichment with reputation UNKNOWN, confidence 0.3, and an explanatory note. Other Shodan failures (401 invalid key, 429 rate limit, 5xx upstream) keep failing loudly so real problems aren't masked.

1.77.11

Reports page: AI-Enhanced cards stop mirroring status onto the non-AI cards + grey out when no local LLM is available

Two related fixes on the Reports page.

  • Status-pill mirroring is gone. Clicking Run on Technical Report (AI-Enhanced) used to make the non-AI Technical Report card's pill flip through “Generating” then “Ready” alongside the AI-Enhanced card's own pill — same for Executive Summary (AI-Enhanced) ↔ Executive Summary. The backend had been collapsing the AI-Enhanced variants into base report types, so two cards ended up tracking one row. Removed the collapse; each card has its own row and its own pill.
  • AI-Enhanced cards grey out when no local LLM is reachable. Without a local LLM, the AI-Enhanced reports would still produce output — identical to the non-AI variant, because the renderer skips AI sections silently. That was a poor signal: the capability difference between the cards was invisible. Cards now render at 50% opacity with disabled buttons reading “Local LLM required”, and hover text pointing at Settings → LLM Provider. The probe shares the same local-LLM status helper that Settings → LLM Provider and the LLM Assistant banner use, so the three surfaces stay consistent.

1.77.10

Help button moves from a floating bottom-right FAB into the sidebar's bottom toggle row

The floating ? Help button — added in v1.77.0 alongside the in-app Help page — was a fixed-position FAB in the bottom-right corner of every page. It worked, but it sat on top of page content (covering toast targets, table footers, the right edge of long charts) and didn't visually belong with the rest of the chrome. Moved into the sidebar's bottom toggle row, between the Cloud Access toggle and the theme toggle. The trio (Cloud Access → Help → Theme) now reads as a single “session controls” cluster, with active-route highlighting when the analyst is on the Help page.


1.77.9

Settings → LLM Provider: per-provider URL retention + accurate “no models” copy + LLM Assistant banner parity

Three connected fixes in the local-LLM stack — two visible UX bugs and one architectural cleanup that prevents the same kind of bug from re-emerging.

  • Per-provider URL retention. Switching providers in Settings → LLM Provider (Ollama → LM Studio → back to Ollama) used to overwrite the URL with the new provider's documented default, even if you had customised the URL on the original provider — a remote custom remote Ollama instance was lost the moment you flipped to LM Studio briefly. Each provider now retains its own URL across switches; the backend merges the active provider's URL into the saved map on every save and refuses to wipe other providers' URLs even when a non-UI client (curl, automation) PUTs only the active provider's fields.
  • “No models found” — accurate copy when the endpoint is unreachable. The Default Model dropdown used to list suggested models labelled (suggested — run: ollama pull <name>) even when the endpoint was unreachable. You can't pull on a server that isn't running, so the suggestion was misleading. Probed-and-unreachable now suppresses suggestions and shows a single placeholder pointing back at Test Connection. Reachable-but-empty still shows provider-specific remedy copy (Ollama → ollama pull llama3.1:8b; LM Studio → “load a model in the Local Server tab”; llama.cpp → “restart with --model …”; etc.).
  • Single source of truth for LLM-status copy. The Settings card and the LLM Assistant page banner both render local-LLM availability strings — and they had drifted. The Assistant banner was hardcoded to Ollama's ollama pull advice even when LM Studio / llama.cpp / litellm was the active provider. Both surfaces now read from a new shared helper (a shared local-LLM status helper) returning provider-aware copy across the three states (ok / no_models / unreachable). Adding a new state — or just rewording one — lands in a single helper, and the two surfaces cannot drift again. Same prevention pattern as the severity- classification parity helpers in v1.57.

1.77.8

/health stops returning HTTP 503 just because Ollama isn't running

Bug surfaced on a v1.77.7 customer VM: GET /health returned HTTP 503 Service Unavailable even though the platform was running fine. Every probe came back 503 — including the storefront's “is the VM up” signal, any external monitoring, and (most damagingly) any reverse-proxy or load-balancer health check, which would now permanently mark the host as down and stop routing traffic to it.

  • Root cause. The health endpoint treated any component being degraded as a 503-worthy condition — including Ollama being unreachable. But Ollama is one of several supported LLM providers (Ollama / LM Studio / llama.cpp / litellm / cloud LLMs from Anthropic, OpenAI, Google), and v1.75.0 made the multi-provider model first-class. Customers running with a cloud LLM, a non-Ollama local provider, or no LLM at all would always get 503 because the probe hard-codes localhost:11434 and treats the absence of an Ollama instance as fatal.
  • Why it matters. LLM features are not on the critical path for IR analysts — collection, parsing, behavioural scoring, IOC triage, kill-chain assembly, blast-radius computation, and reporting all run without an LLM. An IR appliance returning “Service Unavailable” because an optional, non-critical dependency is missing is a serious liveness-probe bug.
  • Fix. Tightened the criticality model: HTTP 200 "healthy" — every critical dependency reachable, no optional components degraded. HTTP 200 "degraded" — every critical dependency reachable, but an optional component (Ollama, future cloud-LLM probes) is unreachable. Body lists which component is degraded; reverse proxies see 200 and keep the host in rotation. HTTP 503 "unavailable" — a critical dependency is down (currently only the system database counts as critical).

1.77.7

PCAP page stops returning HTTP 500 on brand-new investigations

Bug surfaced on a freshly-deployed v1.77.6 customer VM: create a new investigation, navigate to the PCAP page, frontend renders an empty list with a generic error and the backend logs an HTTP 500 error when loading the PCAP data. Same request worked on long-lived investigations that already had evidence stored.

  • Root cause. The PCAP page accessed the per-investigation evidence store directly instead of going through the component that sets up its storage. The PCAP records (and the related flows, DNS, TLS, and IOC records) are only created when the evidence store is initialised on first use for an investigation. On a brand-new investigation that hasn't had any evidence ingested yet, that storage did not yet exist, so the first read failed and the backend returned a 500 error.
  • Fix. The PCAP page now guarantees the evidence store is initialised before any read, transparently setting it up on first use for an investigation. This guard was added to every PCAP action — list, upload, detail, start-analysis, flows, IOCs, DNS, TLS, summary, delete, and enrich. After the first request to a given investigation the result is cached, so there is no measurable per-request cost.
  • Why every PCAP route, not just the failing one. The same pattern would have surfaced as 500s the moment the analyst tried to upload, then start analysis, then view results. Patching the entry-point handler fixes the visible symptom but leaves landmines on every adjacent path. We patched all of them in one change.

1.77.6

Reports stop crashing when the bundled name-recognition model is missing

Bug surfaced on a fresh v1.77.5 VM after Enterprise license activation: every report attempt failed with “Generation Failed — Could not start report generation”. The backend POST /reports call returned 201 Created, but the row landed in FAILED state seconds later. On long-lived dev systems (where the spaCy model had been downloaded once) the same reports rendered cleanly — making it look license-tier or analysis-state related when it was actually a missing runtime asset.

  • Root cause. The PII-detection availability check only verified that the redaction package was installed. It did not verify that the underlying name-recognition model was actually present on disk. So on every report the check passed, then the redaction engine tried to load the model, the model was not found, and the runtime attempted to download it on a sealed appliance image where that is not possible. The failure that raised could not be caught by the report background task's normal error handling, so the task died, the report was marked failed, and the frontend showed the generic error.
  • Defensive fix in the app. The PII-detection availability check now confirms both that the redaction package is installed and that the name-recognition model can actually be loaded. When the model is absent the engine now fails gracefully instead of crashing, and the report falls through cleanly. Reports stop crashing immediately.
  • The proper fix in the VM build pipeline. Customer VM images had several different install steps, some of which silently swallowed download failures and one of which installed the model into the wrong runtime environment — so the application never saw it. The build process now installs the model into the correct environment, fails loudly on any download error, and verifies the model is loadable before the build is allowed to continue. New VM rebuilds will ship with the model present and name/PII recognition fully operational (PERSON / LOCATION names, AU TFN / Medicare / ABN / ACN recognizers used by NDB and CLO reports).

1.77.5

“Analyze Uploaded Evidence” now works on brand-new investigations

A small but blocking bug fix. When an analyst created a fresh investigation, uploaded an EVTX / PCAP / log file, and clicked “Analyze Uploaded Evidence”on the Pipeline card, the backend returned 200 OK and the frontend showed the “Analysis Started” toast — but no IOCs appeared, no timeline events, nothing visibly changed.

  • Root cause. When an analysis was started, the workflow could only advance from an already-running collection state. A brand-new, upload-only investigation that had never been initialised could not make that transition, so it stayed stuck in its initial state while the background analysis ran. The internal phase transitions silently failed and the results were never saved with the new IOCs. Hence the green-toast-then-nothing symptom.
  • Fix. Starting an analysis now initialises a brand-new investigation up front when needed, and the normal pipeline takes over from there. Analysis runs cleanly, IOCs are saved, and the Timeline picks them up.
  • Workaround on existing VMs. Until you can pull the v1.77.5 image, configure any source (even a dummy Entra config) before uploading evidence on a brand-new investigation. That initialises the workflow so the existing analyze path applies.

1.77.4

Security: dependency CVE sweep + Allow-Sensitive-Data toggle on cloud LLMs + Settings card restructure

A meaty security and polish release. Comprehensive dependency audit on both Python and Node sides resolved 35 known CVEs (1 critical, 7 high, 21 moderate, 6 low) by upgrading to fixed versions. Adds a per-provider consent gate that lets analysts opt in to sending sensitive data to specific cloud LLMs (instead of CICADA always force-routing PII to local). Settings → LLM Cloud Provider card reordered top-down so the flow is intuitive.

  • Dependency CVEs. The Python dependency set had 27 known vulnerabilities before the sweep, including a critical (CVSS 9.1) HTTP-client bug and a CVSS 8.7 image-library issue; all were resolved to patch-level fixes. Frontend dependencies were updated to close an SSRF + cloud-metadata exfiltration flaw and an auth-header leak via redirect handling. The full integration test suite (132 tests) passes against the upgraded set — no regressions.
  • Allow Sensitive Data toggle. Settings → LLM Providers gains a second per-provider consent gate. CICADA's default behaviour is to force-route any prompt containing PII or credentials to your local LLM, even when you've chosen Cloud. Some workflows need to opt in — e.g. an enterprise contract with Anthropic that explicitly covers sensitive investigation data. Toggle is layered on top of Allow Cloud Inference: must enable that first. Flipping the toggle on requires a confirm dialog with a strong warning. Per-provider scope — you can opt into Claude while keeping the safeguard on OpenAI. Audit-trail recorded on the backend.
  • Settings → LLM card reordered. The Cloud Provider card now flows top-down: API Key → Test Connection & Fetch Models → Default Model → Allow Cloud Inference → Allow Sensitive Data. The Test Connection button moved up (so it sits directly under the API key) and was renamed to make it obvious that the click also populates the Default Model dropdown.
  • Static-analysis hardening. A static-analysis pass caught and fixed seven real defects (duplicate keys, undefined-name references, dead error-handling branches, and unused variables) plus hundreds of minor style issues, and core modules were re-verified clean.

1.77.3

LLM Assistant — markdown rendering for assistant responses

Until v1.77.3 the LLM Assistant rendered responses as one wall of text with the markdown markup left literal — **bold** stayed as asterisks, numbered timelines bunched together with no indent, and inline code snippets showed their raw backticks. The content was correct but visually flat.

  • Assistant messages now render as proper GitHub-Flavoured Markdown. Headings get scaling sizes (with a divider line under the top-level heading to match the LLM's natural “# Section” outputs); numbered and bullet lists indent with visible markers; inline code becomes an accent-coloured pill; code blocks land in a soft rounded panel with overflow scroll for long lines.
  • Tables. Markdown table syntax (the GitHub | col | col |form) renders as a real bordered table inside a rounded card, with an elevated header row and per-row separators. Particularly useful when prompting the assistant for structured outputs — “Build a markdown table with columns Time, Event ID, Source, Severity, Notes” — for an attack timeline.
  • Section breaks & quotes. Horizontal rules become thin divider lines between sections. Blockquotes get a left accent border + italic styling, useful for the LLM to flag observations vs inferences.
  • Theming. All elements use the existing CICADA design system (the same colours, surfaces, and rounding used elsewhere in the product) so the rendered markdown sits inside the chat bubble without any visual mismatch with the rest of the app.
  • User prompts continue to render as plain text (verbatim, no markdown re-parsing) so asterisks in analyst input don't get reformatted — but the prompt typography was adjusted to match the assistant's body text. No more visual size jump between the two bubbles.

1.77.2

Sources count + Cloud LLM routing + Local-LLM provider scoping fixes

Five reported bugs from one Community Edition tyre-kicking session, all on the LLM Assistant / Settings → LLM / Sources surfaces.

  • Sources count divergence on the Sources page. The Pipeline card and the lower “Configured Sources” pill used to disagree (e.g. 0 vs 1) because they read from two different code paths. Both pills now share the same source array that's refreshed on every add / edit / delete.
  • “Ollama Not Available” when OpenAI is configured.Three compounding routing bugs in the chat backend fixed: the cloud-availability probe now matches the actual cloud-resolution logic exactly, OpenAI-compatible cloud entries get a working feature-gate check, and when the analyst explicitly chooses Cloud the request now fails fast with a clear“Cloud LLM not available — Acknowledge cloud inference is the most commonly missed step” instead of silently falling back to local and dying with a misleading Ollama error.
  • Default Model dropdown labels phantom suggestions clearly. The base CICADA VM image doesn't pre-pull Ollama models. Suggested entries in the Settings → Local LLM dropdown now render with (suggested) suffixes; when Ollama is reachable but has zero models pulled, the suffix becomes(suggested — run: ollama pull <name>) with the exact command to install. A warning-coloured status pill calls out the empty state explicitly.
  • Default Model no longer leaks across providers. Switching from Ollama to LM Studio used to carry the old Ollama model name into the LM Studio dropdown labelled (current), making it look like the dropdown was mixing providers. Stale cross-provider values are now dropped silently when the active provider's probe returns a real model list.
  • LLM Assistant + backend stop hardcoding Ollama. The Configuration sidebar on the LLM Assistant page and the provider-status check on the backend now both honour the analyst's active local provider. The sidebar reads“Local (LM Studio): Connected” when LM Studio is configured; the toggle status reflects whichever local backend is set, not always Ollama.

1.77.1

Active Directory bind — accept bare usernames in addition to UPN and DOMAIN\username

Small but oft-requested polish on the Active Directory source connect form. The Username field used to require either user@domain.com (UPN) or DOMAIN\username(NTLM). Typing just Administrator would fall through to a SIMPLE LDAP bind without a UPN suffix — the LDAP server would then reject it, leaving analysts to re-type the FQDN suffix they'd already filled in on the same form.

  • The Username field now accepts three formats: user@domain.com,DOMAIN\username, or just Administrator. When bare, CICADA combines it with the Domain (FQDN) field on the same form and binds as Administrator@<domain> via LDAP SIMPLE.
  • The bind path now picks the auth method from the input shape up-front (NTLM for backslash, SIMPLE for UPN, SIMPLE+derived-UPN for bare). The pre-existing MD4-fallback path (retry NTLM as SIMPLE+UPN when Python lacks MD4 support) continues to work, routed through the same helper.
  • Helper text under the AD form rewritten so the new flexibility is discoverable inline.

No schema or API changes; pure UX improvement on the AD source connect path.


1.77.0

Community Edition polish — defence-in-depth tier gates, in-app docs, upload-only investigations, sidebar refresh

Follow-up to the v1.76.0 Community launch. Hardens the tier-locked surfaces (frontend route guards plus backend feature gates), unblocks PCAP- and log-only investigations, ships a built-in /help page with a floating help button on every page, and refreshes the sidebar with the full product tagline plus an edition label.

  • Defence-in-depth tier enforcement. v1.76.0 only locked the sidebar nav for Incidents / Case Narrative / Playbooks / Reports — pasting a URL into the address bar bypassed the lock. v1.77.0 adds two layers: a new frontend route guard renders an “Upgrade required” screen, and new backend feature gates for Incidents, Playbooks, and Case Narrative protect the corresponding API endpoints. A free-tier request to a locked endpoint now returns a permission-denied response with an upgrade hint.
  • Run Investigation works for upload-only investigations. Previously the Pipeline card on the Sources page disabled the primary button whenever zero integration sources were configured — ignoring uploaded PCAPs and EVTX / log files. The card now reads “Ready to analyze · 1 PCAP uploaded” and the primary button becomes “Analyze Uploaded Evidence”, skipping the Collect step that doesn't apply when there are no live integrations.
  • Investigation Assistant cleanup. The noisy red “Local LLM Not Available” banner is gone when a cloud LLM is configured. The page-load banner now only surfaces when neither local nor cloud is configured, with friendly copy and a Settings link. The verbose VM-bridged-mode diagnostic moved toSettings → LLM → Test Connection where it belongs. The provider toggle now auto-defaults to Cloud when local is unavailable but cloud is, so analysts don't land on a disabled input.
  • Built-in Help page + floating help button. New in-app/help page covers six topics (Getting Started, configuring data sources, configuring the LLM with the VM-localhost gotcha, network requirements, troubleshooting, license activation), each with a link to the full guide oncicada-ir.ai/docs. Discoverable from every page via circular? button in the bottom-right corner with a hover tooltip; the dedicated sidebar nav entry was removed in favour of the FAB.
  • Sidebar refresh. Sidebar widened from 260px to 288px so the full product tagline (“Cybersecurity & Continuous Attack Detection Agent”) fits on two lines, with a tier-aware edition label below it (Community Edition / Professional Edition / Enterprise Edition / Premium Edition). The standalone Internet toggle bordered section was dropped — Cloud Access lives in the same row as Theme inside the user-block footer now.
  • Tier-aware seat-limit copy. The permission-denied message shown when adding a user and the Settings → Users banner now read“Upgrade to Professional for additional users.” when the seat limit is one (Community / unlicensed); paid tiers see the neutral“Upgrade your subscription to add more users.”

1.76.0

Community Edition release — non-expiring free keys, all cloud LLMs included, single-user limit

This is the public Community Edition launch. The free tier rebrands as Community Edition, becomes permanent (no more 14-day expiry on issued keys), and gains all three cloud LLM providers. The in-app sidebar restricts navigation to the Community feature set with greyed-out, lock-iconned entries pointing analysts at the upgrade path.

  • Sidebar — Community Edition branding + tier-aware nav lock.When the active tier is free, the subtitle below the CICADA logo flips from “IR Platform” to “Community Edition”, and navigation entries outside the Community surface (Incidents, Case Narrative, Reports, Playbooks) render greyed-out with a small lock icon and an “Upgrade to Unlock this feature” tooltip. Clickable on Community: Dashboard, Timeline, Sources, Evidence Store, LLM Assistant, Response Actions, Features, Activation, Settings.
  • All three cloud LLMs are part of the Community Edition. Anthropic, Google, and OpenAI moved from the Premium tier to Free across cicada-app, cicada-admin, this storefront, and the frontend type table. The Local LLM card and the cloud-providers section both work on a Community key out of the box. Premium now retains PII sensitivity detection only.
  • Community Edition keys are now permanent. The trial endpoint issues free-tier keys with no expiry, the cicada-app offline / air-gapped auto-register path skips the 365-day fallback for free-tier keys, and the validator already short- circuits expiry checks on NULL — non-expiring keys validate forever. The 14-day clock on Community is gone.
  • Community Edition is single-user. Free keys ship with a single seat and the existing seat-enforcement path now produces tier-aware copy: at the 1/1 limit, the 403 detail and the Settings → Users banner both read “Upgrade to Professional for additional users.” Paid tiers keep the neutral “Upgrade your subscription” wording.
  • Storefront copy refresh. “14-day trial licence” replaced with “free forever” on the pricing page Community card, the homepage FAQ answer, and the FAQPage JSON-LD that Google reads — so the schema-marked answer matches the visible copy.

1.75.0

Local LLM consolidation — one card, four backends, no more Ollama-vs-OpenAI-compatible split

Settings → LLM used to surface local-LLM configuration as two separate cards (Ollama Settings + OpenAI-compatible endpoint, plus a “Runs on our network” checkbox to override Ollama). The conceptual model worked for engineers but confused analysts — most users want to pick onelocal LLM, not configure two and toggle a flag. Worse, the LLM Assistant page hardcoded Ollama on load, so analysts who configured LM Studio were still told “Ollama Server Not Available”.

  • A single Local LLM card replaces both legacy cards. Provider dropdown picks Ollama / LM Studio / llama.cpp server / litellm proxy / Custom OpenAI-compatible. The card's URL field, model picker, and Test Connection probe all adapt to the chosen provider.
  • The “Runs on our network” checkbox is gone. Picking your local provider implicitly trusts it for sensitive context routing. Cloud OpenAI-compatible endpoints (Groq, Together for cloud rotation) keep the existing cloud-providers section.
  • Migration is automatic. The first read of the new settings inspects your existing local and OpenAI-compatible configuration and infers the active provider — if the OpenAI-compatible endpoint was treated as local, the new provider is inferred from the URL pattern (port 1234 → LM Studio, port 8080 → llama.cpp, etc.). Otherwise defaults to Ollama.
  • LLM Assistant fix. The page now reads which local provider is active and probes it correctly. Banner copy adapts: “LM Studio Not Available”, “llama.cpp server Not Available”, etc. No more stale Ollama errors when you're running LM Studio.

1.74.7

Sidebar — Response Actions badge correctly anchored on collapsed sidebar

When the sidebar was collapsed, the red Response Actions pending-count badge appeared at the very top of the collapsed pane instead of attached to the Response Actions icon. The parent nav-item button was missing position: relative, so the absolute-positioned badge fell back to the nearest positioned ancestor (the fixed sidebar itself). Now anchored correctly to the icon.


1.74.6

Dashboard KPI rail — symmetric four-cell row, breakdown lives on Timeline

Removed the Critical / High severity chips from the Alerts KPI cell. The cell now reads 1684 / Alerts with the same visual shape as every other cell in the rail — Configured Sources · Events Ingested · Alerts · Actions Taken. Clicking the Alerts cell navigates to the Timeline page, which already has dedicated Critical and High filter tabs. The breakdown lives where the analyst acts on it, the rail stays a row of symmetric headline numbers.


1.74.5

Dashboard Alerts cell — coloured-text chips with dot separators

Dropped the pill backgrounds on the Critical / High chips. They now render as coloured text (Critical in red, High in amber) with a · separator between the label and each chip — “Alerts · 9 Critical · 9 High”. Same click-to-filter behaviour, but no geometric weight competing with the small label.


1.74.4

Dashboard Alerts cell — Critical / High chips inline with the label

Reverts the v1.74.3 peer-cells experiment (Critical and High should not have full KPI visual weight) and the v1.74.1 / v1.74.2 chip-placement attempts. The chips are back on the Alerts cell, but now sit on the same line as the “Alerts” label instead of below it. Both elements share the small label typography, so the alignment problem from earlier attempts disappears — the chips and label baseline-align naturally because they share the same text size.


1.74.3

Dashboard KPI rail — Critical & High promoted to peer cells next to Alerts

The Critical / High severity counts no longer ride along on the Alerts cell as sub-chips. They're now first-class KPI cells sitting directly next to Alerts: Configured Sources · Events Ingested · Alerts · Critical · High · Actions Taken. Same visual weight as every other cell, same click-to-filter-Timeline behaviour, same icon / colour conventions (Critical → danger red, High → warning amber).


1.74.2

Dashboard Alerts cell — chips moved to the right edge, stacked vertically

The previous v1.74.1 placement put the severity chips inline with the bold count value, which read as visually unaligned because of the size mismatch. They now sit in their own column on the right edge of the cell, stacked vertically — the value + label keep the cell's left side, the chips own the right.


1.74.1

Dashboard Alerts cell — severity chips inline with the count

The Critical / High severity chips on the Dashboard's Alerts KPI cell used to render on a separate row below the label, which visually divorced them from the count they explain. They now render on the same baseline as the count itself. Same data, denser presentation, scannable in one read.


1.74.0

Frontend design-system overhaul

Top-to-bottom visual reskin of the frontend. New monochromatic palette in both themes (GitHub-Dark style for dark mode, professional-light for light), new typography scale (16px base, h1–h4 at medium weight), and a unified 88px heading bar across every page so the divider line never jumps when navigating.

  • Sidebar reskin — solid background (no glassmorphism), full-width active nav block, “IR Platform” subtitle, and Theme + Sign-out moved into the sidebar bottom. The old top Header bar is gone.
  • Six new design-system primitives — tabs, a KPI rail, banners, empty states, filter bars, and data tables. Used across Dashboard, Sources, Timeline, Settings, Incidents, Evidence Store, LLM Assistant, Response Actions.
  • Primary buttons are monochromatic — a high-contrast dark/light block instead of brand blue. Splash, Dashboard banner, and the New / Resume / Import investigation modals all match the same visual register.
  • Settings → Users table previously rendered with broken styling because it referenced a styling token that no longer existed. It is now driven by the shared data-table component and themed correctly.

Backend behaviour unchanged. Existing pages keep their data wiring while inheriting the new visual treatment through tokens.


1.73.1

Pipeline card tweak — Review step no longer spins during reporting

Report PDFs are an automated artifact of the finished converge step, not work the analyst should wait on. Review is now marked done as soon as analysis converges, the badge reads Generating reports while PDFs are produced in the background, and the status line tells you to start reviewing the findings now.


1.73.0

Pipeline card — one surface for collection / analysis status

The Sources page used to surface the run-investigation lifecycle across six separate UI elements: five tinted phase banners (Collection in Progress / Analysis Phase / Correlating / Convergence & Graph / Action Required) plus a standalone Run Investigation card with up to 11 different button labels. Each phase change shifted layout. The mental model “where is the pipeline, what should I do next?” took six surfaces to read.

  • One unified pipeline card replaces all six. Horizontal stepper (Collect → Analyze → Correlate → Converge → Review), an adaptive status line, and a single primary action button whose label matches what you can actually do right now — Start Collection when you're fresh, Re-run Collection when you have data, Re-analyze / Add More Data when the pipeline is waiting on input, Stop always findable on the right when applicable.
  • Dashboard onboarding nudge clears once data exists. The “Ready to collect data” banner used to keep reappearing after every successful collection because the underlying check was “no agent currently running” — sitting next to a 49-event dataset with copy that read as fresh-state. Now strictly an onboarding banner: shows on a fresh investigation, disappears after the first successful collection. Re-runs live on the Sources page's Pipeline card.

1.72.1

Live-test follow-up — collector toast count + Timeline severity parity

Two surface-inconsistency bugs caught during a real Entra collection on the test VM. Same theme as v1.71.0 (IOC truthfulness): the analyst was being shown a number / severity that didn't match the underlying data.

  • Source-card toast no longer overstates IOC count. The collector's high-confidence IOC counter was incrementing on the raw extraction yield before the noise filter ran — so the post-collection toast could read “7 IOCs” while only 3 actually persisted to the IOC table. Counter now matches the Dashboard and the IOC detail view.
  • Timeline failed-auth severity matches IOC severity. A single failed Enterprise App signin used to render as Alert: Authentication at High on the Timeline, even though the underlying event was severity=low and the IOC it produced was severity=medium — a violation of the Timeline ↔ Dashboard severity-parity invariant. A solitary failed auth now correctly stays at medium; brute-force aggregation across repeated failed logons still earns High for repeated failures from the same source.

1.72.0

Engine integrity unification — chain-of-custody and evidence in one DB

Closes the architectural gap that let chain-of-custody records live in a legacy shared evidence database while the evidence they described lived in the per-investigation evidence database. A forensic export could show a partial or empty custody trail even when the records had been written — they were just in a different database file.

  • Chain of custody binds to the per-investigation database. Custody records now resolve to the same database the evidence lives in, and the custody schema is created there. A lazy migration copies existing records from the shared database across on first access.
  • Source collection routes through the per-investigation registry. The Sources page used to write evidence to the legacy shared database directly — so collector data and uploaded log / PCAP data lived in different files. It now uses the same per-investigation evidence store the rest of the platform uses.
  • Single shared event bus. Sources had its own internal event bus, distinct from the one driving live updates. Collection-progress events published into it never reached frontend subscribers. Both now publish to the same bus.
  • Content-sampling retention now persists a real deletion record. Detaching a playbook instance triggers the retention sweep — bytes older than the retention window are purged and marked as removed per retention policy, and the purge appears in the chain-of-custody export endpoint, not just the application log. (The 1.70.0 release notes claimed this; 1.70.1 retracted; 1.72.0 delivers.)

1.71.0

IOC truthfulness — canonical IOC API, collector noise filter, honest extraction metric

Three fixes that close the gap between “what CICADA tells the analyst about IOCs” and “what's actually persisted in the IOC table.” All three cluster naturally around analyst trust — if the dashboard says we found 47 IOCs, the API should return those same 47, and the engine shouldn't have hidden 200 benign noise hits inside that count.

  • The IOC API now reads the canonical IOC store. The endpoint used to scan the first 1000 normalized evidence records and harvest IOCs from a metadata field that the persistence path doesn't actually write to. It now serves directly from the canonical IOC store, the same source the dashboard, timeline, and behavioural engine use. The response now includes status, severity, threat score, behavioral score, reputation level, first / last seen, and occurrence count, plus a new status filter for suspected / confirmed / cleared.
  • Collector mirrors the IOC extractor's noise filter. The extractor already drops benign Microsoft / Google / Windows-update telemetry, successful-auth IPs, and MD5/SHA1 duplicates of an existing SHA-256. The real-time collector path didn't mirror that check, so noise IOCs flooded the IOC table, dashboards, and enrichment queues. Now skipped at persistence time. New collector ingest stops contributing noise; existing investigations are not retroactively cleaned.
  • Honest extraction metric. The extracted-IOC count previously counted every regex match in raw text extraction — but the text-extract path doesn't persist its matches; only the parallel event-log path does. Reports therefore overstated by 4–5× on real investigations. The extracted-IOC count now means “persisted to the IOC store” (counted after extraction completes) and the raw-hit count moves to a separate candidates-scanned figure for diagnostic value.

1.70.1

Audit-driven hotfix bundle — chain-of-custody, fail-closed feature gates, admin-only license activation

Independent engine and security review on 27 April 2026 identified a small cluster of high-confidence defects that warrant a fast patch ahead of the larger v1.71 / v1.72 work. None are new regressions in v1.70.0; most pre-date the 1.70 line. They're fixed now because they directly weakened forensic integrity (chain of custody silently no-op'd) and tier enforcement (paid-feature gates fail-open on errors).

  • Chain of custody fixed. Two evidence write paths were calling a method name that didn't exist on the chain-of-custody component; every custody log threw an error and the surrounding catch swallowed it. New collector ingest and dispatched response actions now reliably get a custody row, and future CoC failures surface as warnings instead of disappearing.
  • Feature gates fail closed. Six paid-tier route gates plus the Sources gate used to grant access on any unexpected error from the feature manager. They now return 503 Service Unavailable until the gate can answer authoritatively.
  • License activation is admin-only. The license-activation endpoint had no role guard — any authenticated caller could swap the global tier. It now requires an administrator role.
  • Frontend FeatureGate respects backend disabled state. A feature you turn off in the admin panel is now actually locked in the UI even if the customer's tier defaults would have permitted it.
  • What's New panel shows the unseen slice. Now displays only releases newer than the last one you saw and writes the “seen” marker only on dismissal, not on initial open.
  • Demo seeding awaited. Startup demo response-action seeding was firing a background task that was never properly awaited, so seeded actions sometimes failed to appear in demo mode. Fixed.
  • Documentation corrections. The 1.70.0 entry overstated content-sampling retention (the sweep helper is built but not yet wired to detach or a scheduler — v1.72.0) and counted a sibling internal test repository when it claimed “132 tests passing”. Both retracted in the changelog.

1.70.0

Three-tier PII classification — real content sampling via endpoint live-response

The CLO Affected-Files Listing now classifies every file the compromised user touched through a deterministic three-tier pipeline with full per-tier provenance. Every row on the PDF is defensible — the analyst can point at any flag and say which tier saw what.

  • Tier 1 — filename LLM. Local Ollama classifies filenames with a DLP-analyst system prompt, returning risk and category tags per file. Keyword regex fallback when Ollama is unreachable — the report stamps “T1 degraded” so forensic reviewers can see the classifier used the lower-confidence path.
  • Tier 2 — Presidio over path entities. On-device spaCy NER (en_core_web_lg) + Presidio's checksum-validated recognizers catch PERSON names, EMAIL, AU TFN / Medicare / ABN / ACN, and credit cards that leak into filenames or directory structure. Runs fully on-device — no content leaves the CICADA appliance.
  • Tier 3 — real content sampling. Pulls up to 50 files × 64 KB of actual file content via configured adapters, runs Presidio over the extracted text, and writes the sampled bytes to the evidence store with a SHA-256 and a 30-day retention TTL. Integrations ship for:
    • Microsoft Defender for Endpoint — full Live Response flow (machine lookup, fetch the file, poll until ready, download via result link). Requires the appropriate Defender for Endpoint live-response permission.
    • CrowdStrike Falcon — full Real Time Response admin flow with session management and extracted-file-contents retrieval. Requires Real time response admin (write) scope.
    • Microsoft 365 / SharePoint / OneDrive — Graph /drives/…/content with a dedicated Files.Read.All token, separate from the Management Activity API token.

Content sampling is a Professional-tier feature. When off, Tier 3 evidence records“disabled” on every file for transparency; the report ships with Tier 1 + Tier 2 signals only. When on, the analyst confirms content-sampling per investigation the first time it fires, and every sampled file is ranked by existing Tier 1/2 flag strength so the highest-signal files sample first and any rate-limit hits fall on the lowest-signal ones.

The report preview surfaces a Classification provenance panel showing per-tier status badges — ran / degraded / unavailable / disabled / rate-limited / no adapter — so an IR lead reviewing the report knows exactly which pipeline stages contributed to every classification. A Likely PII count now sits alongside Confirmed PII, letting the CLO distinguish strong signals from weaker ones at a glance.


1.69.0

Playbooks — scenario-driven IR wizards

CICADA now ships a first-class Playbooks sidebar surface that walks analysts through scenario-specific IR workflows one decision at a time. The framework launches with one playbook — Credential Compromise — and a declarative shape that future playbooks (ransomware, BEC, insider threat, stolen laptop, supply-chain) will plug into as each ships.

  • Six step archetypes. Every playbook composes the same set of card shapes — Input, Auto, Review, Approval, Report, Handoff — so analysts learn the shape once and every playbook feels familiar. Each card has a one-click “see details” expander so the happy path stays opaque and fast while the “something's off” path is always one click away.
  • Runs on top of an existing investigation. Attach a playbook to an in-flight investigation at any time; detach if it turns out not to apply. Multiple playbooks can run in parallel for an investigation that spans multiple scenarios (we surface them as tabs).
  • Retroactive by default. Auto steps query the evidence store first instead of triggering fresh collection. Per-task completeness indicator (empty / partial / complete) tells the analyst whether the investigation's existing evidence covers enough of the window or whether a supplementary collection is warranted.

Credential Compromise playbook

The first shipped playbook encodes the credential-compromise IR workflow end-to-end. Given a compromised user principal and a time window, it:

  • Aggregates authentication, Kerberos ticket, endpoint, file-audit, and mailbox events already in the evidence store.
  • Expands scope via new logon-to pivot analyser that walks the authentication graph to every host / server / share the compromised user touched. Confidence scoring per entity based on source breadth; UPN / NetBIOS / bare-SAM name variants all resolve to the same identity.
  • Queues four containment response actions (Disable user, Revoke sessions, Isolate endpoints, Block file hashes) for you to approve in bulk. Targets resolve server-side (no client-side template injection), are validated against canonical shapes per target type, and land in the Response Actions page pre-approved with your email on the audit log.
  • Produces the CLO Affected-Files Listing — a new PDF + JSON report purpose-built for legal handoff. Every file the compromised user touched, grouped by host / share, with on-device PII classification (TFN, health, financial, contact categories) flagged on each row. Cover page includes the OAIC Notifiable Data Breach disclaimer for the CLO's review.
  • Hands off with next-step copy pointing to the CLO, so the analyst knows exactly what to email and who to send it to.

The playbook respects CICADA's existing approval model: every destructive action still requires explicit approval, but now the analyst's click is the audit event (stamped with their email), so the four-step Approve All ceremony is a single decision rather than four.


1.68.0

Analyst triage upgrade — MITRE tooltips, benign dismissal, one-click hash block

Seven Timeline-facing changes that move the page from a read-only event list into a first-class triage surface. You can now understand why an IOC scored the way it did, dismiss the noise you've already chased down, and push a response action — without ever leaving the Timeline.

  • MITRE ATT&CK tooltips. Hover any purple technique badge (T1078, T1021.002, T1059.001, …) on a Timeline row to see the technique name, tactics, platforms, a short description, and a link out to attack.mitre.org. 691 techniques ship in the product — no external network calls at runtime. If MITRE publishes an ATT&CK update between CICADA releases, the bundled library is refreshed in the next release build.
  • Mark-as-benign dismissal. The eye-off icon on each IOC card toggles it as analyst-dismissed with an optional reason. Dismissed events are hidden from the default Timeline view and re-surfaced via new Show Benign toggle — rendered dimmed with a muted pill when visible so the analyst can see what they've already cleared without those rows competing for attention.
  • “Why this severity?” disclosure. Every behaviour IOC now has a one-click expander that shows the engine's categorization reason, the list of matched Tier 1 / Tier 2 pattern IDs, and the ordered evidence chain with each signal's score contribution. Finally explains why a PCAP row that rendered LOW before Run Investigation lands at HIGH after — the specific signals (sequence match, baseline breach, responder flag) that pushed it up.
  • Block File Hash from Timeline. SHA1 / SHA256 / MD5 IOCs now get a dedicated Block Hash quick-action on the expansion panel that creates a file-hash block response action directly. No more copy-paste detour through the Response Actions page for every hash you want to blocklist in CrowdStrike Falcon.
  • CSV log ingest. Sources → Log File now accepts .csv uploads alongside .log / .txt. The parser auto-detects the delimiter (comma / semicolon / tab / pipe), reads the header row, and maps common SIEM-export column names (timestamp, @timestamp, src_ip, source_ip, user, username, action, outcome, message…) onto the canonical fields. Unknown columns pass through verbatim so downstream IOC extraction still finds IPs, URLs and hashes that live in custom fields.
  • Timeline identity enrichment (T1078 / 4648). Timeline rows for “Valid Accounts” / “logon with explicit credentials” events now always name which account was used — e.g. — CORP\svc_backup on FS01. Previously the upstream field extractor couldn't populate the target-account fields for Event 4648's Account Whose Credentials Were Used section, so the Timeline rendered a bare technique label. Now enriched defensively at render time from whatever identity metadata the orchestrator did capture.
  • PCAP re-analyze flag fix. The Re-analyze with NEW DATA pill no longer lights up immediately after the very first Run Investigation completes. The fresh-data flag is now cleared when the full pipeline starts, matching the existing clear on the partial Skip to Analysis path.

1.67.1

Report generation queue + seven UI fixes

  • Reports now queue properly. Clicking Run on a second report while the first is still generating used to fail silently — both reports fought for Ollama at the LLM layer and the second appeared stuck. Now the second report is marked Queued (amber clock), runs as soon as the first finishes, and status transitions (queued → generating → ready) appear on the page within 3 seconds without requiring a refresh.
  • If the backend restarts mid-generation, any in-flight reports are swept to failed with a clear “Server restarted during report generation — please rerun” message instead of being stuck in generatingforever.
  • Timeline filter dropdowns (All Types / All Severities / All Statuses) now sit horizontally in a single row instead of stacking vertically.
  • Reports “Ready” / “Generating” pill is now centre-aligned within its table cell for consistent visual weight.
  • Sidebar investigation names show the full name on hover when truncated.
  • Sources → Log File upload now refreshes the Uploaded Evidence list immediately — no more manual page reload required to see the new file.
  • Sources catalog cleanup: the duplicate “Syslog” and “Syslog Server” entries (both pointed at the same backend adapter, one would have silently failed at Test Connection time) are consolidated into a single Syslog Server entry with the correct RFC 3164/5424 description.

1.67.0

Bring-your-own LLM — llama.cpp, LM Studio, litellm, and friends

The LLM Assistant and report narrative engine now talk to any OpenAI-compatible /v1/chat/completions endpoint alongside the existing Ollama support. Configure once in Settings → OpenAI-compatible endpoint and both the chat assistant and the report generator use your chosen backend.

  • Preset-driven setup — one-click defaults for LM Studio (localhost:1234/v1), llama.cpp server (localhost:8080/v1), litellm proxy (localhost:4000/v1), or Custom for anything else.
  • Smart model picker — probes the endpoint to detect whether it's llama.cpp, LM Studio, or litellm, then populates the model dropdown from/v1/models plus a curated fallback list per preset. For llama.cpp it also pulls the actually-loaded model name from /props so the UI shows exactly what the server is running. No free-text model input anywhere.
  • Operator-declared privacy posture — the “Runs on our network” checkbox decides where CICADA routes your data. Checked → the endpoint replaces Ollama in the local slot and sensitive evidence is allowed. Unchecked → the endpoint joins the cloud rotation and requires the standard cloud-inference acknowledgement. An RFC1918 / loopback detector suggests the right default and warns loudly when the URL and the declaration disagree.
  • Works with compat-mode cloud vendors too — Groq, Together, DeepSeek, OpenRouter, Azure OpenAI, or any vendor that implements the OpenAI Chat Completions shape, as long as you declare them non-local and tick the cloud-inference acknowledgement.

Polish — three smaller fixes bundled in

  • Guided IR “Complete” pill turns green when the terminal phase is reached. Previously stayed amber because the terminal phase was treated as “active” forever.
  • Support bundle now tells you where to send it. A “Send to: support@cicada-ir.ai” hint row with a pre-filled mailto: link sits next to the Download button. One-business-day SLA noted inline.
  • Activation page always shows a pricing link — if your install doesn't have a white-label storefront URL configured, it falls back to cicada-ir.ai/pricing so analysts without a key aren't stuck at a “Contact your administrator” dead-end.

1.66.2

Multi-file upload for Log Files

  • Drop multiple log files at once into the Log Files source, same pattern as the Event Viewer uploader — per-file queue, status chips, dedupe, running summary. Previously you could only upload one .log or .txt file at a time.
  • Max file size bumped to 500 MB per file (was 100 MB) to align with the backend's actual limit. No more 100 MB rejection on files the backend would happily accept.

1.66.1

CSV log upload + IOC noise filter

  • PowerShell CSV exports now ingest correctly. Event log uploads accept the modern Get-WinEvent | Export-Csv column shape (Id, TimeCreated, ProviderName, LevelDisplayName, Message) in addition to the older Event Viewer GUI export shape. Files that previously parsed as zero events now ingest cleanly, and the error message tells you which columns were found vs. expected when something doesn't match.
  • System log noise filter. The IOC extractor now skips known-benign Microsoft, Google, and Windows-update telemetry domains (fs.microsoft.com, gvt1.com, akamaized.net, onenote.net, and friends) so a System log from a healthy Windows host doesn't produce 100+ noise IOCs that lock up threat-intel enrichment for minutes.
  • ThreatFox enrichment hardening. Defensive fix for a pre-existing crash when ThreatFox returns a non-list response shape — no more internal type errors flooding the logs during enrichment.

1.66.0

Beta feedback sweep — ten fixes and a backup rework

  • Client Exposure save now persists to investigation scope — clients you declare in the Client Exposure panel show up in Guided IR, the Blast Radius report, and Report Notify instead of silently vanishing after save.
  • Backup & restore carry credentials across instances. Full backups now include the encrypted credential store and the master key. Investigation backups embed an encrypted secrets manifest that gets re-encrypted under the destination’s master key on restore. Cross-instance imports no longer silently drop every Source credential.
  • Microsoft Defender response actions. Quarantine File now advertises the correct Machine.StopAndQuarantine scope; Block IP / Block Domain advertiseTi.ReadWrite. New Unblock IP and Unblock Domain actions reverse previous blocks automatically — pass the indicator id or just the value and CICADA looks it up and deletes it.
  • Blast Radius report no longer crashes with undefined-variable errors on zero-identity investigations or pre-v1.62 data — defensive defaults on every optional field.
  • Reports IOC counts — Executive Summary IOC count now matches the Dashboard. Previously the Exec Summary rendered 0 IOCs even when the Dashboard showed dozens.
  • LLM Assistant investigation overview, IOC list, and MITRE summary are now budget-reserved so the IOC section can’t be truncated away under tight context budgets. Summary mode carries the full IOC list.
  • Response Action tooltips — hover any action card on the Response page to see the full description plus verification steps (“verify in Defender > Indicators”, “filter by indicator id in Falcon”). Block File Hash success message now includes the Falcon IOC Management link and the exact filter to confirm the block is active.
  • Ollama unreachable error for VM users — when the Ollama test fails with a localhost URL, the error now explains that localhost inside a VMware Fusion / Parallels / VirtualBox VM is not the host Mac/PC, and lists three concrete fixes (bridged adapter + host LAN IP, OLLAMA_HOST=0.0.0.0, or run Ollama inside the VM).

1.65.0

Declared compromised accounts drive detection everywhere

  • Accounts you declare as compromised at investigation creation now immediately appear across Dashboard, Timeline, IOC lists, and Incidents — no waiting for the engine to rediscover them from raw events.
  • Declared identities are matched across their variants (DOMAIN\user, user@domain, bare user), so every event for the same identity ties back.
  • Timeline rows tied to declared identities show a red “Declared Compromised” chip so analyst-supplied accounts are visually distinct from engine-discovered ones.
  • The Incidents page shows a stub card for each declared account before behavioral analysis runs, then folds cleanly into the real incident once kill chains are built — no duplicates.

1.64.0

Evidence page renamed to Evidence Store

  • The page at /evidence is now labelled “Evidence Store” — a clearer description of what it is: a file-manifest view of the raw artefacts a source has collected. Existing bookmarks and deep-links keep working.

1.63.0

Credential-edit regression fix

  • Fixed a bug where editing a source without re-typing the password could drop the stored secret, causing Test Connection to fail with “invalid credentials”. Affected Active Directory, Entra ID, Microsoft Defender, CrowdStrike, and Varonis sources on v1.61 and v1.62.
  • If affected: after upgrading, re-open the source, re-enter the password once, and save. No further action needed.

1.62.0

Blast Radius Report

Answers the question every IR engagement needs to answer for legal, regulators, and the board: what could the attacker access vs what did they actually access?

  • Per-identity breakdown — reachable resources, accessed resources, sensitive subset, and dwell time per principal.
  • Sensitivity heatmap — resources split by tier (restricted, confidential, internal, public) with exposed vs confirmed-accessed counts and data-subject estimates.
  • Regulatory exposure cards — records and individuals affected mapped to NDB (Australian Privacy Act), GDPR Art. 33, HIPAA, PCI-DSS, and APRA CPS 234 so notification decisions come straight off the report.
  • Transitive grant paths — shows resources reachable only via group or role inheritance, separated from direct ACL grants.
  • Telemetry-gap callouts — flags windows where access can't be confirmed or refuted so the exposure delta is read with the right caveat.
  • Prioritised recommendations — actions across containment, IAM, monitoring, and notification.

1.61.0

Page-by-page UX audit — six pages, one sweep

  • Sources — credential fields no longer pre-populate with stored values when editing. Closes shoulder-surfing, clipboard, and autofill capture of saved API keys, client secrets, and passwords.
  • Case Narrative — clicking Exclude / Undo on a compromised entity no longer resets it to “likely unaffected”. Entity-graph right-click failures now surface as toasts instead of being silently swallowed.
  • Evidence — integrity-check results now report actual valid/invalid file counts instead of always claiming success.
  • LLM Assistant — auto-scroll during streaming, clear-history wipes in-memory state, citation refs pivot to Evidence on click.
  • Reports — download filenames are sanitised, and failed reports now show the actual error message instead of a dead-end “Failed” label.
  • Response Actions — bulk password reset via CSV now validates coverage before submission so users aren't disabled without their new credentials being handed to IT.

1.60.0

Real attack-path trajectories + Dashboard UX pass

  • Real entity-to-entity attack paths — Incident cards now show the compromised identity hitting each real host in sequence, with deduped hops per unique host pair. Replaces the previous “actor > actor” self-loop placeholder.
  • Open in Timeline works everywhere — actor chips, entity targets, kill-chain links, and the header button on Incidents all now route to Timeline › Evidence Events with the identity pre-filled.
  • Dashboard polish — Configured Sources count is accurate on freshly-configured investigations; stat cards are clickable through to their pages; Key Findings surfaces lower-severity indicators when none are critical/high; Dashboard tab selection round-trips through the URL.

1.59.0

Detection patches from the multi-breach audit

  • Suspicious admin-name detection — flags accounts whose very name suggests a red-team leftover or an attacker-created backdoor (hack1, backup_admin, temp_admin2, pwn*). Solo activity triggers medium severity; joining an admin group escalates to high. Deliberately narrow so hackathon-style names and the literal Administrator don't match.
  • Firewall-traced lateral movement — pairs Windows network logons with Windows Filtering Platform allow events to corroborate lateral-auth windows from the firewall side. A companion pattern detects blocked outbound traffic after credential access — a signature of C2 or exfil attempts hitting egress filtering.

1.58.0

Hierarchical Incidents — multi-breach separation

  • New Incidents entry point — kill chains now cluster into distinct coexisting breaches. One enterprise with an APT on the DC and a cryptominer on a dev laptop sees two separate incident cards rather than one flat IOC pile. Drill into each incident to see attack paths, member kill chains, and the step list.
  • Human-readable cluster reasons — every merge explains itself (“shared IOC 10.0.5.12”, “handoff on dc01 within 15 minutes”). Two legitimate concurrent admins stay separate — merges require a concrete shared signal.
  • Re-cluster on demand — one click rebuilds incidents from the current kill chains without re-running collection. Useful after tuning detections or clearing IOCs.

PCAP pipeline overhaul

  • Wireless (802.11) forensics — captures that previously reported “no IP traffic” now produce a full breakdown: SSID inventory, BSSID tracking, client MAC sightings, deauth-flood detection, WPA 4-way handshake capture, and open-AP detection.
  • Wireless indicators as first-class IOCs — deauth-flood attacker MACs, WPA handshake client MACs, and observed SSIDs flow through the same enrichment and IOC store as IP / URL / hash indicators.
  • Clearer invalid-PCAP diagnostics — error messages now identify Microsoft NetMon, Windows .etl, plain-text log files misnamed as .pcap, and unknown formats.
  • Threat-intel enrichment 30× faster — parallel provider lookups with non-routable IPs filtered before they hit external services.
  • Active Directory collection unblocked — active ADs now collect ~20k events per DC per run (previously capped at 2000).

1.57.0

PCAP parser rewrite, Dashboard and AD fixes

  • PCAP parser — full per-link-type support. Raw 802.11, radiotap, Linux cooked (SLL/SLL2), BSD null/loopback, PPP, and raw-IP captures now decode correctly. Previously these silently produced 0 flows with no diagnostic.
  • Clear explanations on 0-flow PCAPs — wireless auth captures now say so explicitly; wired L2-only captures note possible ARP/STP/LLDP-only content.
  • Timeline Critical count matches Dashboard — IOCs promoted to critical via threat-intel reputation now show consistently across both pages.
  • Active Directory collection no longer capped at 2000 events. Each event log channel now honours its own limit, so active ADs collect ~20k events per DC per run.

1.56.0

Tiered IOC engine overhaul + 8 new AD detections

  • 8 new AD attack patterns — Zerologon, DCShadow cleanup, AdminSDHolder modification, pre-auth-disabled (ASREPRoast prep), medium-window brute force, hour-scale password spray, Silver Ticket, and interactive admin logon.
  • Per-actor kill-chain narratives — detected sequences assemble into attack narratives ordered by MITRE tactic (Recon → Credential Access → Lateral → Persistence). Severity rolls up by tactic breadth.
  • Detection feedback loop — analyst confirm / clear decisions feed system-wide calibration. Patterns with chronic false-positive rates can be auto-disabled.
  • New LSASS-dump signatures — COMSVCS MiniDump (fileless), native MiniDumpWriteDump API, Invoke-DCSync, secretsdump.py, Invoke-NTLMRelay, legacy dumpers (WCE, pwdump, fgdump), KRBTGT password reset.
  • Timezone correctness — all event timestamps are normalised to UTC at ingest, fixing mixed-timezone crashes and impossible-travel miscalculations.

1.55.0

Investigation export fix & production readiness audit

  • Investigation export — encrypted .cicada-inv backups now work on deployments using cookie-based local auth (previously failed to send session cookies with the request).
  • Production readiness audit — full security and code-quality review completed across the analysis engine, API, licensing, integrations, reporting, and frontend.

1.54.0

Dashboard UX & NIST framework reference

  • Dashboard cards — “Active Sources” renamed to “Configured Sources” (integration sources only, excludes uploaded PCAPs/logs). New card order: Configured Sources | Evidence | Alerts | Actions Taken.
  • Response actions counter — updates within 10 seconds; Timeline quick-actions refresh the counter immediately.
  • Guided IR — panel now references the NIST SP 800-61r2 Computer Security Incident Handling Guide framework.

1.53.0

Observability, support bundle & UX fixes

  • Support bundle — generate a downloadable diagnostic ZIP from Settings > Support. Logs are automatically sanitised (IPs, emails, UUIDs redacted) so you can inspect before sharing with our support team.
  • Runtime log level toggle — change log verbosity from the API without restarting the service.
  • Log rotation — automated daily log rotation (7 days retained, 50 MB max per file).
  • Timeline quick-actions fixed — Block/Isolate/Disable buttons correctly detect available adapters and show a picker when multiple are configured.

1.52.0

Local user authentication

  • Username/password authentication — air-gapped and LAN deployments no longer require Cloudflare Access. Create local users with username and password directly in the platform.
  • Setup wizard admin account — first admin user is now created during initial setup.
  • User management UI — Settings > Users tab with add, edit, delete, disable, and password reset.
  • Seat enforcement — user count limited by the seats field in your product key, managed via your licence tier.
  • Security hardening — OWASP ASVS Level 2 reviewed with peppered bcrypt hashing, JWT fingerprinting, refresh token rotation with theft detection, and exponential backoff on failed logins.

1.50.0

Feature gating, tiered reporting & 14-day free trial

  • Tiered reporting — Investigation reports (executive summary, technical, MITRE mapping, blast radius, attack path, AI-enhanced) available at Professional. Compliance & legal reports (NDB, insurance, legal hold, regulatory, client exposure, executive briefing, IR playbook, post-incident review) available at Enterprise.
  • 14-day free trial — download-link trial flow with email delivery, no credit card required. (Later restructured: the permanent free tier rebranded as Community Edition, and the 14-day trial unlocks Professional features — see v1.74.x.)
  • Active Directory moved to the free tier — all users can now connect to on-prem AD out of the box.

1.49.0

Behavioral engine hardening

  • Major accuracy improvements to the behavioral scoring engine — fewer false positives from service accounts, SYSTEM log operations, and correlated weak signals.
  • PowerShell deobfuscation — detects encoded commands, backtick escapes, and character-array obfuscation before pattern matching.
  • New detection patterns: WinRM lateral movement, slow-and-low brute force, slow lateral movement campaigns.

1.48.0

Ubiquiti UCG firewall integration & source selection redesign

  • Ubiquiti UniFi Console Gateway integration — collect firewall logs and block/unblock IPs. Supports API key and session-based authentication.
  • Source selection at investigation creation — when creating a new investigation, you now choose which data sources to import upfront. No more sources appearing automatically.

1.47.0

Correlation engine & detection coverage expansion

  • Correlation engine — individual detections now aggregate into entity-level correlated findings. Severity escalates when multiple MITRE tactics are observed for the same entity.
  • 12 attack chain templates — temporal sequence matching for common attack flows: credential dump → lateral movement, brute force → compromise, full kill chain, DCSync + Golden Ticket, ransomware precursors, and more.
  • 17 new Windows Event IDs — domain policy changes, Zerologon/Netlogon, LSASS dump via SilentProcessExit, PowerShell pipeline, MSSQL xp_cmdshell, BITS persistence, Credential Manager, and more.
  • Evidence Events tab — search by entity name to see all normalised evidence events where they appear as actor or target.
  • Noise reduction — successful auth IPs no longer create spurious IOCs, SHA1/MD5 duplicates removed, system accounts filtered from blast radius.

For the full changelog including all bug fixes and technical details, contact support@cicada-ir.ai.