AccuKnox v3.6 Release Notes¶

v3.6 closes loops that used to need a person. A finding moves to Fixed on its own once a follow-up scan agrees the problem is gone, and the ticket you raised closes with it. Checks that do not apply to your environment switch off, onboarding an AWS account drops the access keys, and red teaming writes prompts for what your model is actually for.

What's New¶

Pick an area to see what changed in it.

FindingsCloudPoliciesPlatformRuntimeAI SecurityAppSec

Findings Lifecycle Automation. Active moves to Waiting for Verification, then to Fixed, once two scans agree. The linked ticket closes with it.
Status Logs on Cloud Findings. Every status change on a finding shows who made it and when.
Smart Tickets: Parent-Child Automation. The Rule Engine creates the parent ticket on the first run, then attaches new findings to it on later runs.
SBOM License Findings. Open-source license obligations become their own finding type.

Checks Management. Switch any cloud check off per account, or re-rate its severity. Findings, compliance, and reports all follow.
Simplified AWS Account Onboarding. Launch a CloudFormation stack, paste the role ARN, then click verify. No long-lived access keys are stored.
SAMA Cyber Security Framework. Score your AWS accounts against the Saudi financial sector framework.
Security Graph. See the assets around a finding or an asset, and how an attacker could move between them.
Microsoft 365 SSPM Scan. Scan a Microsoft 365 tenant against the CIS benchmark and read the findings under SARIF.

Policy Builder for AWS SCP. Create and manage Service Control Policies without leaving AccuKnox.
Policy Import, Export, and Bulk Actions. Runtime policies move between environments as YAML files.
Trigger Execution Count and Notification Channels. Every trigger reports how often it fired, and one trigger can notify several channels.

New Categories Added to Event Trail. Certificates, cloud accounts, collectors, policies, and registries join the audit log.
Central Certificate Store. Upload a certificate once, then reuse it across integrations.
New Dashboard Widgets. Top 10 rankings, severity breakdowns, and asset trends join Dashboard V3.

STIG and CIS Coverage for Ubuntu 22.04 and 24.04. Four DISA STIG and CIS Benchmark profiles now cover Ubuntu hosts.
KubeArmor Updates. KubeArmor gains kernel-native DNS enforcement, file integrity hashes, hostname regex matching, and ECS Fargate support.

Red Teaming Moves to the Assets Page. Start a scan and read its risk detail where the models already live.
Intelligent Red Teaming Scans. Describe what the model is for and AccuKnox generates prompts for that purpose.
Gen AI Prompt Firewall. The browser plugin covers three more platforms, and policies can block uploads by file type.

Authenticated DAST Scan with MFA. Record a login flow once and scan behind it, TOTP codes included.

Findings and Workflow¶

Findings Lifecycle Automation¶

A cloud finding now carries its own lifecycle, and scan cycles move it along without anyone editing a status field.

Active means the check is still failing.
Waiting for Verification means one scan found the problem resolved and AccuKnox wants a second scan to agree.
Fixed means the follow-up scan confirmed it.

The two-scan rule exists so a single quiet scan does not close something prematurely. Statuses are set by the system, and you can still override any finding by hand when you need to.

When a finding reaches Fixed, the ticket AccuKnox raised for it in Jira or your other connected ticketing system closes automatically. You no longer have to reconcile a closed finding against an open ticket.

Status Logs on Cloud Findings¶

Cloud finding detail gains a Status Logs tab. Every status change on that finding is listed with:

The status it moved from and the status it moved to.
Who made the change. Automation is attributed to System (Rule Engine), and a person shows by name.
The date and time it happened.

A status you did not expect is now quick to explain.

Other data types

Status Logs is a per-finding view for cloud findings. For every other data type, Event Trail carries the same status history along with the rest of the audit timeline.

Smart Tickets: Parent-Child Automation¶

v3.5 let you nominate a Parent field when the Rule Engine creates a ticket. v3.6 removes the manual work around it:

On the first run, the Rule Engine creates the parent ticket for you.
On every run after that, it attaches newly discovered findings to the parent that already exists.

The parent field is optional. Pick the field you want to group by, and its value becomes the parent ticket name.

Available grouping keys include Status, Location, Asset Name, Asset Type, Label, Vulnerability Name, Data Type, Risk Factor, and Unique Vulnerability Name.

In Jira the parent lands as a Story or an Epic and each finding becomes a task or sub-task underneath it. Before this change, every run produced a flat set of unrelated tickets and grouping them was a manual job.

Prerequisite

You need a connected ticketing integration such as Jira before the Rule Engine can create tickets. This automation lives on the Findings → Rule Engine page.

SBOM License Findings¶

Open-source license data was already inside the SBOM files AccuKnox generated. v3.6 surfaces it as its own finding type. Choose SBOM License Findings in the data type dropdown on the Findings page, and each row gives you:

Component name and version
License name, such as MIT, BSD-3-Clause, or ISC
License type, such as Permissive
Risk factor and the asset the component belongs to

Permissive licenses are labelled as such, so anything more restrictive stands out. Obligations become visible at review time instead of at audit time.

List view first

License findings are available at list level in this release. The per-finding detail drawer follows in a later release.

Cloud Security and Compliance¶

Checks Management¶

Not every check matters in every account. Settings → Checks Management lets you switch individual cloud checks on or off, and change the severity a check reports, per cloud account.

A change here follows the check everywhere it appears:

Findings page
Findings Summary
Compliance page
CSPM reports, which use the severity you set rather than the default
Tool findings view

To work through the list:

Filter by severity, status, cloud provider, or asset category.
Tick the checks you want to change.
Use Change Status to enable or disable them, or Change Severity to re-rate them.

The page covers each supported cloud provider, so an Azure account is managed the same way as an AWS one.

Before this, a check you had no intention of acting on still counted against your compliance score and still showed up in every report you sent out.

Scope

Checks Management applies to CSPM and cloud findings.

Simplified AWS Account Onboarding¶

Onboarding a standalone AWS account used to mean generating an access key and secret key, or running a Terraform script and managing the IAM permissions yourself. v3.6 replaces that with a role handshake.

Choose STS Assume Role - External ID as the connection method.
Click Launch CloudFormation Stack and run it in the AWS console you are already signed in to.
Copy the IAM role ARN the stack produces and paste it into AccuKnox.
Click Verify & Connect.

No long-lived keys are stored on either side, and there is no script to install locally.

Scope

Assume role with external ID is available for AWS standalone accounts in this release. Other cloud providers continue to use their existing connection methods.

SAMA Cyber Security Framework¶

The SAMA Cyber Security Framework, published by the Saudi Central Bank for the Saudi financial sector, is now a supported CSPM compliance framework. Select it from the Compliance page to score an AWS account, see the compliance percentage, and drill into each control.

Expand a control such as 3.3.6 Application Security to see the individual checks behind it and open any failing check directly.

Each finding also shows which frameworks and controls it maps to, so one failed check tells you every obligation it touches at once.

Security Graph¶

Scanning already told you an S3 bucket exists and that it has logging disabled. What it never told you was what sits around that bucket. Security Graph draws those relationships: asset to asset, and asset to finding. Every edge is a real relationship, which is how you read blast radius. Compromise one node and the graph shows what else is reachable from it.

There are two ways in, and they answer different questions.

Asset graph. Go to Inventory → Cloud Assets, open an asset, then the Security Graph tab. The graph centers on that asset and draws everything related to it plus the findings on each one. This is the wider of the two views.

The EC2 instance above is the attack path in one picture. An Internet node connects straight to it, and the edges run out to its VPC, subnet, security group, and attached IAM identities. An attacker who reaches the instance inherits those identities and can pivot along those edges. Reading that from a list of findings takes a lot longer.

Findings graph. Go to Issues → Findings, open a finding, then the Security Graph tab. This one is scoped to that single finding and shows which other assets carry it, so you can tell whether a misconfiguration is isolated or spread across the estate.

The same finding on several assets always draws the same way, so this view is stable to share. From either graph you can click a node to open its findings inline, or load more related assets and findings for that node.

The badge on a node flags major issues only, not every finding. An instance that is publicly exposed with logging off and a public IP assigned gets a marker. A single low-severity check does not. That keeps the graph readable on an asset carrying hundreds of findings.

Security Graph is on by default with nothing to configure. It covers cloud findings on AWS, Azure, and GCP.

Run a scan first

The graph is built from scan data, so an account with no completed scan has nothing to draw. A scheduled or an on-demand scan both work.

Load time

A finding with many connected resources takes longer to draw than a simple one.

Microsoft 365 SSPM Scan¶

SaaS Security Posture Management now scans Microsoft 365 tenants. On 3 August 2026, CERT-In and CSIRT-Fin issued a Critical advisory about a campaign against Microsoft 365 in the Indian BFSI sector. The accounts it reached had MFA turned on, so configuration is what separated an exposed tenant from a safe one.

Setting it up takes three steps:

Go to Settings → Integrations → Collectors and pick SaaS Security Posture Management.
Add a collector, set Integration Type to Microsoft 365, then enter the tenant ID, client ID, client secret, and MS 365 tenant domain.
Give it a label and save.

The collector runs on demand, and the list shows how many findings and assets it returned on its last run.

Findings land under Issues → Findings with the data type set to SARIF Finding. Each one carries its CIS Microsoft 365 Benchmark control ID, a severity, an SLA, and what to change.

The benchmark score for the tenant appears on the Compliance page alongside your other frameworks.

Policy Management¶

Policy Builder for AWS SCP¶

Policy Builder in v3.6 covers AWS Service Control Policies. Create, view, update, and delete SCPs against the organization units in your connected AWS organization, without leaving AccuKnox.

The organization unit list comes from your cloud account, so turn on AWS SCP Support while onboarding the account. It sits on the Security Configuration step next to CSPM and AI Security.

If no connected account has AWS SCP Support enabled, the organization unit dropdown in Policy Builder stays empty and policy creation is blocked. Enabling it on an account is the fix.

Policy Import, Export, and Bulk Actions¶

Runtime policies can now move between environments as files, and bulk actions cover the rest of the policy list.

Export downloads the policies you selected as YAML. Select several and you get a single multi-document YAML file rather than a folder of separate ones.
Import reads that same YAML back. If a policy in the file already exists, it updates in place instead of creating a duplicate, so re-importing an edited file is safe.
Enable and Disable now work across a multi-selection, so you no longer open policies one at a time to change status.
Accept All and Reject All apply to auto-suggested policy changes across every policy you selected.

Filter the list to the policies with Changes available first when you are reviewing suggestions, so an accept action only touches policies that actually have something pending.

Trigger Execution Count and Notification Channels¶

Every alert trigger now reports a Trigger Count, so you can tell at a glance which rules are firing and which have never matched anything. A trigger sitting at zero is usually a filter that needs a second look.

Expand a trigger to see the filters behind it. When you create or edit one, you can send it to more than one notification channel at a time, including Jira and Slack.

Platform¶

New Categories Added to Event Trail¶

Event Trail covers more of the platform. Five categories join the audit log in v3.6:

Certificates, including who deleted one and when
Cloud accounts
Collectors
Policy Manager
Registry Manager

Filter the log by category to isolate one area, such as every change made to your channel integrations. Each row carries:

Timestamp
Message describing what happened
Component and action, for example channel_updated
Result, passed or failed
Owner, meaning the account that made the change

Expand a row for the full detail.

The list is organized by category rather than by the specific object, so open a row when you need the exact channel or account a change applied to.

Central Certificate Store¶

Certificates now live in one place. Upload a signed certificate once, then reuse it instead of uploading the same file into each integration separately. Splunk integration and registry onboarding both read from this store, and every upload and deletion is recorded in Event Trail.

New Dashboard Widgets¶

Three widget families join Dashboard V3, and they are available across ASPM, CSPM, and CWPP.

Top 10 widgets rank your noisiest findings and assets. Open Add Widget, search for Top 10, and pick from the module you want.

Added to the dashboard, they give you a ranked read of cloud findings, container images by vulnerability count, SAST results, and DAST results side by side.

Findings by severity breakdowns run through the same widgets, so a ranked list such as Top 10 Cloud Accounts with Most Findings splits its count into critical, high, medium, and low.

New asset trends plot the assets discovered over your selected date range. Read it next to the new findings trend:

The asset trend tells you whether your inventory is growing.
The new findings trend tells you whether your scanners are still finding things.

A flat new-findings line on a growing estate usually means a scanner stopped running.

Hover the i icon on any widget to see what it measures before you commit space to it on the dashboard.

Host and Runtime Security¶

STIG and CIS Coverage for Ubuntu 22.04 and 24.04¶

Ubuntu hosts can now be scanned against DISA STIG and CIS Benchmark profiles. Four profiles ship in v3.6, covering just over a thousand controls in total:

Profile	Source
Ubuntu 22.04 STIG	DISA STIG V2R8
Ubuntu 24.04 STIG	DISA STIG V1R5
Ubuntu 22.04 CIS	CIS Benchmark v3.0.0
Ubuntu 24.04 CIS	CIS Benchmark v2.0.0

Pick STIG Findings in the data type dropdown on the Findings page. Each row names the control, the host it applies to, its risk factor, and the profile it came from, so you can filter to one profile or one host.

Open a finding for the control text, why it matters, and the exact remediation step.

Automated and manual controls

Roughly half of the controls in these profiles are checked automatically. The rest are manual controls that a benchmark leaves to the assessor, so they are listed for you to attest rather than scored by the scanner.

KubeArmor Updates¶

Hostname matching in policies. The hostname label now accepts a regular expression, or a comma-separated list of hostnames, so one policy can target a group of nodes (PR #2640).
File integrity hashes in alerts. Logs and alerts can carry the IMA hashes of a process and its parent, which lets you confirm that the binary that ran is the binary you shipped (PR #2170).
DNS enforcement in the kernel. A new matchDNSQueries rule audits or blocks lookups of specific domain names, enforced through BPF LSM (documentation).
GKE Autopilot. KubeArmor deploys on Google Kubernetes Engine Autopilot clusters. See Install on GKE Autopilot.
AWS ECS Fargate. Runtime protection now runs on ECS Fargate tasks.
x86-64-v3. The instruction set is supported, so newer hosts run the optimized build.

AI Security¶

Red Teaming Moves to the Assets Page¶

Red teaming used to live behind an activate and deactivate toggle with no control over what a scan did. In v3.6 the whole flow sits on the Assets page next to the models it tests, so you see an asset and start a scan against it in the same place.

Three things are new here:

New Scan replaces the toggle with a guided setup flow.
Show All Configurations lists every scan configuration in your tenant, with its scan type, categories, models, status, and when it last ran.
Risk detail opens from any risk count in the table.

Click a risk count and the detail view opens on Overview, with the risk score, the cumulative trend, findings by severity, and a per-category breakdown.

Insights goes a level deeper, listing every goal the scan attempted inside each category with its failure rate, so you can tell base64 injection apart from package hallucination rather than reading one blended score.

Findings shows the prompt sent, the model's response, the goal it tested, and the severity, which is where you go to check whether a failure is real.

Scope

The new scan flow covers managed models. Unmanaged models are not included.

Intelligent Red Teaming Scans¶

A generic prompt set finds generic problems. v3.6 adds a second scan mode that writes prompts for what your model is actually for.

Static Scan runs a fixed set of general prompts from the existing library. Fast to set up, broad coverage.
Intelligent Scan generates prompts from a purpose you describe, so a medical assistant gets medical prompts and a coding copilot gets coding prompts.

Under Scan By you choose where the prompts come from:

Describe Model Purpose generates a fresh set for the purpose you type. Preset purposes such as Customer Support, Coding Copilot, and Legal Risk Scanner fill the field for you, and you can edit the text.
Prompt From Library reuses a set you generated earlier. Several agents that share a purpose can share one prompt set instead of regenerating it each time.

Generated prompts are grouped by category, with a count per category. Select whole categories, or expand one and pick individual prompts.

The full setup runs in four steps: pick the scan categories, choose library prompts or describe the purpose, review and select the prompts, then schedule the scan. One configuration can cover several models, so three models serving the same purpose go into one scan.

Prerequisites

Models have to be onboarded first, and AccuKnox needs only the model invocation permissions it already uses. There is nothing extra to grant.

Where library prompts live

Saved prompt sets are stored per tenant. A set you create appears under Prompt From Library for your tenant only.

Gen AI Prompt Firewall: Browser Plugin and Attachments¶

The Gen AI browser plugin now covers five platforms: ChatGPT, Claude, Gemini, GitHub Copilot, and Microsoft Copilot. All five are enabled as soon as the plugin is active, and a prompt that breaks policy is blocked in the page before it reaches the model.

File attachments are covered too. Add the Attachment Type scanner to a policy, choose the extensions you allow, and an upload outside that list is denied. Blocking PDFs and videos across every user is one policy change.

Only the extension is sent

The plugin reads the file extension and sends that value for evaluation. The file itself is never uploaded to AccuKnox.

The same policies apply whether traffic arrives through the browser plugin or the API.

Uploads, not artifacts

Files you upload are scanned. Files the model generates for you are not monitored in this release.

Application Security¶

Authenticated DAST Scan with MFA¶

A DAST scan that stops at the login page only tests your login page. v3.6 adds a recorder-based login method to the Authenticated scan type, and it handles multi-factor authentication.

Choose Browser Plugin based Recorder as the login method:

Install the AccuKnox Recorder browser extension from the link on the page.
Record your application's login flow once and upload the resulting file.
Enter the username and password the scanner should use.
Turn on Multi-Factor Authentication (MFA) and paste your TOTP secret key, then set the algorithm, digit count, and period to match your authenticator.

The recorder replays the exact steps you performed, which handles multi-step and scripted logins that a form fill cannot.

Getting your TOTP secret

Your authenticator app's setup screen shows the secret key behind the QR code, usually under a "can't scan the code" or "enter key manually" link. Copy that value into Secret Key.

Manual Login remains available as the lighter option. You supply:

Login URL
Username and password
An indicator string the crawler looks for on the page after login, which is how it confirms the session worked

The indicator text has to be updated whenever the post-login page changes, so the recorder is the more durable choice.