Home Automation Triage Engine Knowledge Check Knowledge Check (Pro) Note: Triage Engine is a DefectDojo Pro-only feature.
Twenty questions about what Triage Engine is for, and how its rules are built, run and delivered. Pick an answer to see whether it’s right and why. Your first pick is the one that counts toward your score, but you can then pick the other options to see where each one would point you. Each explanation links to the page that covers it. Nothing is recorded: your answers stay in your browser and disappear when you leave the page.
1. What is Triage Engine?A.
A scanner that finds new vulnerabilities in your Assets
B.
A visual automation builder: each rule is a graph of nodes that decides when it runs and what happens to the items that flow through it
C.
A machine-learning model that scores and prioritizes Findings
D.
A dashboard that summarizes open Findings by severity A rule is a graph: one trigger node that decides when the rule wakes up, wired to logic, Finding, Asset and egress nodes that say what happens next.
Read more Where to look instead: DefectDojo doesn’t scan. To pull results from your scanners automatically, connect them with Upstream Connectors.
Upstream Connectors →
Where to look instead: Scoring and ranking Findings is the job of Priority & Risk, which you tune with a Prioritization Engine.
Priority, Risk and SLAs →
Where to look instead: For severity summaries at a glance, build a Customizable Dashboard.
Customizable Dashboards →
2. What does Triage Engine add over the original Rules Engine?A.
Branching, sending to outside systems, a full record of every run and send, and a simulate mode for safe testing
B.
Only a faster way to apply the same filter-plus-actions rules
C.
Automatic conversion and retirement of all your existing rules
D.
Rules that run without needing an owner or permissions It keeps the filter-plus-actions capability and adds four things: branching, egress, traceability through Runs and Deliveries, and Simulate mode.
Read more Where to look instead: If a filter plus a list of actions is all you need, the original Rules Engine still does exactly that.
Rules Engine →
Where to look instead: Nothing converts on its own. When you’re ready, the converter creates disabled copies for you to review.
Converting from Rules Engine →
Where to look instead: Every rule runs as its owner. To widen what a rule can reach, assign an owner with wider access, or use Take Ownership .
Rule owners →
3. Which of these is a good use for a Triage Engine rule?A.
Running a scanner against an Asset on a schedule
B.
Writing a parser for a new scan format
C.
When a Critical Finding is created, opening a JIRA issue and posting to Slack, while only tagging lower-severity Findings
D.
Changing which users can log in to DefectDojo An If / Filter node splits Findings into a true and a false branch, so one rule can ticket and notify on Criticals and treat the rest differently.
Read more Where to look instead: DefectDojo doesn’t run scanners, but Upstream Connectors sync your tools’ results on a schedule. A rule can then react with the When a Scan Has Landed trigger.
Upstream Connectors →
Where to look instead: For a format with no built-in parser, the Universal Parser lets you map it without writing code.
Universal Parser →
Where to look instead: Who can log in is managed by your identity provider. SCIM provisions and deprovisions users automatically.
SCIM Provisioning →
4. Besides Findings, what else can Triage Engine rules work on, and why is that useful?A.
Users, to automate onboarding and offboarding
B.
Assets, to keep inventory organized: setting fields, tagging, moving them between Organizations and enforcing that as new Assets arrive
C.
Scan files, to rewrite them before import
D.
Nothing else. Rules only ever work on Findings An Asset rule can set fields, move Assets between Organizations, tag them and place them in the hierarchy, and keeps enforcing that grouping instead of needing a one-off migration.
Read more Where to look instead: To onboard and offboard users automatically, provision them from your identity provider with SCIM.
SCIM Provisioning →
Where to look instead: To import a format DefectDojo doesn’t parse, map it with the Universal Parser instead of rewriting files.
Universal Parser →
Where to look instead: Rules can work on Assets too: use the On Asset Event trigger and the Assets nodes.
Asset nodes →
5. Your team already relies on rules in the original Rules Engine. What happens to them when Triage Engine is turned on?A.
They keep running unchanged. Both engines run side by side, and you can convert rules when you’re ready
B.
They are converted to Triage Engine graphs automatically
C.
They stop running until you convert them
D.
They are deleted after 30 days Turning on Triage Engine doesn’t disable or convert existing rules, and there’s no deadline to move them. A converter is there for when you want to.
Read more Where to look instead: Nothing converts on its own. Run the converter when you’re ready; it starts with a --dry-run report.
Running the converter →
Where to look instead: They keep running, and you’ll find them under Act > Classic Rules .
Rules Engine →
Where to look instead: Nothing is deleted. Only Triage Engine’s own run and delivery records are pruned, after 180 days by default.
Retention settings →
6. What is the Deliveries page for?A.
Scheduling when rules run
B.
Configuring Slack and JIRA credentials
C.
Listing scan imports that are still in progress
D.
Showing everything rules sent, or would have sent, outside DefectDojo: what was sent, where it went and how it ended Every outbound send is one row in the delivery ledger, written before the network call, so egress is auditable and simulated sends can be reviewed.
Read more Where to look instead: Schedules are set on the rule itself, with an On a Schedule trigger.
Scheduling →
Where to look instead: Slack and Teams credentials live on a Messaging Connector under Connect > Downstream . The Triage Engine nodes send through that connection, not the System Settings Slack and Teams setup.
Messaging Connectors →
Where to look instead: To act when an import finishes, use the When a Scan Has Landed trigger. To catch a scan that never arrived, use On a Missing Scan .
Scan triggers →
7. A Finding’s severity changed overnight and nobody knows why. How does Triage Engine help answer that?A.
It doesn’t. You’d have to read every rule definition
B.
The Finding shows a provenance timeline naming the rule, run and node that made each change
C.
It emails the rule owner every time a Finding changes
D.
Rule changes are hidden from the Finding history Provenance answers “why did this Finding change?” on the Finding itself, with before and after values, and it survives the rule being deleted.
Read more Where to look instead: No need: each run’s node trace on the Runs page shows what every node did.
The node trace →
Where to look instead: To get told about changes, add a Send an Email node to the rule, or set up your personal notifications.
Send an Email node →
Where to look instead: Rule changes are shown on the Finding. For a wider record of who changed what, use Audit Logs.
Audit Logs →
8. What do Webhook Receivers let Triage Engine do?A.
Let Slack users run rules from chat commands
B.
Expose a public API for other tools to create rules
C.
React to events from outside systems, such as closing a Finding when its linked Jira issue is marked Done, or adding Jira comments as notes
D.
Send scan reports from DefectDojo to external tools Receivers accept inbound webhooks and hand them to rules. For Jira this gives two-way sync: closing, reopening and comments flow back to the linked Finding.
Read more Where to look instead: Rules don’t take chat commands. To run one on demand, give it a Manual Run trigger and press Run .
Manual Run trigger →
Where to look instead: Rules are built in the Pro UI. To let another tool start a rule, point it at a custom Webhook Receiver.
Webhook Receivers →
Where to look instead: Sending things out is egress. Use the Generate a Report or Call a Webhook node.
Generate a Report node →
9. How is Triage Engine turned on?A.
It turns on automatically when you upgrade to a release that includes it
B.
A superuser turns it on from Settings > Feature Flags
C.
Each user turns it on in their profile
D.
An admin sets DD_RULES_V2_ENABLED=True in the environment Triage Engine is in Beta and off by default. A superuser turns it on with a feature flag, on both Cloud and On-Premise.
Read more Where to look instead: Upgrading doesn’t turn it on. A superuser enables it under Feature Flags.
Feature Flags →
Where to look instead: It’s switched on for the whole instance. Who can use it is then set by the four Rule permissions.
Rule permissions →
Where to look instead: The DD_RULES_V2_* settings only tune throughput, retention and egress. The feature itself is a feature flag.
Configuration →
10. What state is a newly created rule in?A.
Enabled, in Live mode
B.
Enabled, in Simulate mode
C.
Disabled, in Live mode
D.
Disabled, in Simulate mode New rules are always created disabled, so enabling one is a deliberate act. Simulate is the default mode.
Read more Where to look instead: You switch to Live yourself, as the last step after checking the simulated deliveries.
Testing a rule safely →
Where to look instead: You enable a rule yourself, once Preview shows it matches what you expect.
Preview →
Where to look instead: Simulate is the default. Live is something you switch on.
Simulate and Live →
11. A rule in Simulate mode contains a Set Severity node and a Send a Slack Message node. What happens when it runs?A.
Nothing changes and nothing is sent
B.
Severity changes on the Findings, and the Slack message is recorded as a simulated delivery but not sent
C.
The Slack message is sent, but Finding changes are rolled back
D.
Both happen, but the run is labeled as a simulation Simulate is not a partial run. Every Finding edit happens for real; only the outbound sends are held back.
Read more Where to look instead: For a dry run that changes nothing at all, use Preview . It runs the real engine, then rolls everything back.
Preview →
Where to look instead: To send messages without editing Findings, build a rule with only egress nodes and set it to Live.
Egress nodes →
Where to look instead: That describes Live mode, where both the edits and the sends happen.
Simulate and Live →
12. A rule’s trigger has an empty Scope . Which Findings does the rule consider?A.
Every Finding in the instance
B.
No Findings, because scope is required
C.
Every Finding the rule’s owner can see
D.
Every Finding the user who last edited the rule can see Scope is applied on top of authorization, never instead of it. The rule runs as its owner.
Read more Where to look instead: A rule only sees what its owner sees. For instance-wide coverage, make the owner a user who can see everything.
Rule owners →
Where to look instead: Scope is optional. To narrow a rule, add scope filters, the same ones the Findings list uses.
Scope →
Where to look instead: Rules run as their owner, not their last editor. To make yourself the owner, use Take Ownership .
Rule owners →
13. A Finding rule’s scope contains a filter key that doesn’t exist. What happens at run time?A.
The run errors out
B.
The bad filter is ignored and the rest of the scope applies
C.
The scope widens to everything the owner can see
D.
The rule is automatically disabled An invalid scope fails the run rather than widening it. A rule that does nothing is recoverable; one that edits everything is not.
Read more Where to look instead: When converting old rules, --drop-invalid-filters drops unknown filters with a warning instead of failing.
Converter options →
Where to look instead: Use Preview to see what a scope matches before you save.
Preview →
Where to look instead: The rule stays enabled. Read the error on the Runs page and fix the scope.
Runs →
14. A run’s third node raises an error after the first two nodes edited 200 Findings. What is the outcome?A.
The 200 edits are kept and the run is marked partial
B.
All Finding changes are rolled back, the node trace and error are still recorded, and no deliveries are sent
C.
Everything is rolled back, including the trace, so the run leaves no record
D.
The run retries from the failed node A run is atomic, but the trace is written afterwards. Deliveries are dispatched only after the run commits.
Read more Where to look instead: Runs are all or nothing. The node trace shows which node broke.
The node trace →
Where to look instead: The trace is kept even when the edits roll back. Open the run from the Runs page.
Runs →
Where to look instead: Runs don’t resume. Fix the node and let the rule run again. Failed sends can be replayed from Deliveries.
Replaying a delivery →
15. How does Triage Engine handle concurrency?A.
One instance-wide lock, so only one rule runs at a time
B.
No locking, so a rule can run several times in parallel
C.
Rules run one at a time, in the order of their weight
D.
Each rule runs once at a time, and different rules run concurrently A rule can have only one run in progress. Distinct rules run concurrently, unlike the original engine’s instance-wide lock.
Read more Where to look instead: That’s how the original Rules Engine works. Triage Engine locks per rule instead.
What changes when you convert →
Where to look instead: A rule never races itself; a second trigger waits. To change how big each run is, tune Findings per event.
Throughput settings →
Where to look instead: Rules have no run order. For steps that must happen in order, chain the nodes inside one rule.
The editor →
16. Rule A changes a Finding, which triggers Rule B, which changes it again in a way that would trigger Rule A. What happens?A.
Rule A doesn’t run again, because a rule never runs twice in the same chain
B.
Rule A runs again, up to a depth of 3
C.
Both rules loop until the stall window kills them
D.
The second change is blocked and Rule B errors Every event carries the list of rules already traversed in its chain, so rules cannot re-trigger themselves or ping-pong.
Read more Where to look instead: To revisit Findings regularly instead, sweep them with an On a Schedule trigger.
On a Schedule trigger →
Where to look instead: Loops can’t happen. The stall window is for runs whose worker died.
Run lifetime settings →
Where to look instead: Nothing is blocked; Rule A just doesn’t fire again. Follow a chain with the Depth and Source run fields.
What a run records →
17. A scheduled rule’s scope matches 250,000 Findings. With default settings, how many does the run process?A.
1,000, the chunk size
B.
500, the events-per-batch size
C.
All 250,000, processed in chunks of 1,000
D.
10,000, the run safety cap A run is not capped. Chunk size bounds memory, not coverage.
Read more Where to look instead: Chunk size only limits memory. To cap a run on purpose, add a Limit node.
Limit node →
Where to look instead: 500 is how many Findings one event carries. Tune it with DD_RULES_V2_EVENT_BATCH.
Throughput settings →
Where to look instead: There’s no built-in cap. To cap how many tickets or messages a run produces, add a Limit node.
Limit node →
18. A rule tries to open a JIRA issue for a Finding that already has an active delivery with the same idempotency key. What is recorded?A.
A second JIRA issue is created
B.
Nothing. The send is silently dropped
C.
The run fails with a duplicate-key error
D.
A skipped delivery row with the reason in the last error field The double-send guard allows one active delivery per key. A colliding send becomes a visible skip, never a duplicate ticket.
Read more Where to look instead: Duplicates are blocked. To send again on purpose, replay a failed or dead delivery.
Replaying a delivery →
Where to look instead: Skips are never silent. Each one shows its reason on the Deliveries page.
Delivery statuses →
Where to look instead: To avoid repeat sends within one run, add a De-duplicate Within Run node.
De-duplicate Within Run →
19. You save a rule whose Call a Webhook node points to http://10.0.0.5/hook. With default settings, what happens?A.
The rule saves, and the send fails at run time
B.
The rule saves and sends normally
C.
The URL is rewritten to https
D.
The save is rejected because the host resolves to a private address, unless DD_RULES_V2_ALLOW_PRIVATE_EGRESS is turned on Loopback, link-local, private, reserved and multicast hosts are rejected at save time by default, to stop request forgery from inside the cluster.
Read more Where to look instead: Destinations are checked when you save, so a bad URL fails early.
Destination validation →
Where to look instead: To allow private addresses, turn on DD_RULES_V2_ALLOW_PRIVATE_EGRESS.
Destination validation →
Where to look instead: URLs aren’t rewritten. For ready-made outbound alerts, see Messaging Connectors.
Messaging Connectors →
20. You convert Rules Engine rules with python manage.py convert_rules_to_v2 and no extra options. Which statement is true?A.
Converted rules are enabled, and the originals are disabled
B.
Converted rules are disabled, and their schedules are not copied unless you pass --activate-schedules
C.
Converted rules keep their run history from the old engine
D.
Every Rules Engine action, including “set false positive to false”, converts automatically Converted rules always land disabled, and schedules are copied only with
--activate-schedules. Run history stays put, and “set false positive to false” must be converted by hand.
Read more Where to look instead: You enable converted rules yourself. Follow the suggested order, with Simulate first.
A suggested order →
Where to look instead: Run history stays in the original engine’s UI.
Rules Engine →
Where to look instead: Run --dry-run first to see which rules need converting by hand.
Converter options →
