ISTQB Specialist (CT-STE v1.0.1) Mock Exam #4 — Questions & Answers
Every question in this mock exam, with the correct answer marked and a written rationale behind each option below — for reading and review, not a timed run.
Chapter 1 · Security Paradigms — 6 questions
A port terminal operator has classified its systems into three protection levels: the gate access and container release system (highest), the berth-planning system (medium) and the public arrivals display (lowest). How should these protection levels influence the security testing effort?
Testing effort is distributed evenly across the three systems, because uniform coverage is what makes the findings comparable and the overall result defensible.
Comparability of findings is not the goal of a security test. Spending the same effort on a public display as on container release ignores the difference in consequences and wastes effort where little is at stake.
The depth and rigour of testing is scaled to the protection level, so the gate access and container release system is tested earliest and most thoroughly.
Correct. The security level assigned to an asset expresses how severe a compromise would be, and the syllabus uses that level to drive how much security testing the asset receives and when.
Testing effort follows the size of each codebase, because the number of security defects in a system grows roughly with the amount of code it contains.
Defect density is a development metric, not a risk metric. A small component holding the release authorisation can carry far more risk than a large display application.
Testing effort follows how recently each system changed, because a system that has not been modified keeps the security status it had at its last release.
Change is one input to prioritisation, but an unchanged system does not keep its security status: new vulnerabilities are published for components that nobody touched.
The CT-STE syllabus ties the rigour of security testing to the security level assigned to the asset. Information sensitivity and the consequences of a compromise determine how deeply and how early a system is tested, which is why the gate access and container release system takes priority over the arrivals display.
An online pharmacy keeps three data sets in one database cluster: the public product catalogue, internal stock levels, and dispensed-prescription records. Which approach to the protection level of that shared store is appropriate?
The shared store is protected at the level of the most sensitive data it holds, so the prescription records set the level that security testing has to verify.
Correct. An attacker who reaches the store reaches everything in it, so the highest sensitivity present determines the controls and the depth of the testing.
The store is protected at the level of the data set that is queried most often, because the exposure of the data grows with the number of requests that reach it each day.
Request volume describes load, not sensitivity. The catalogue is queried constantly and needs the least protection, while the prescription records are queried rarely and need the most.
Each data set keeps its own protection level inside the shared cluster, so the access control applied at the database layer covers the prescription records alone.
Per-data-set levels are a reasonable design goal, but leaving the other sets unprotected at the database layer gives an attacker a foothold inside the same cluster from which to reach the records.
The store is protected at the average of the three levels, because that balances the cost of the controls against the sensitivity of the data that is actually held.
Averaging protects the most sensitive data below its required level. Cost is managed by separating the data sets, not by lowering the protection of the one that matters most.
When data of different sensitivity shares one store, the store inherits the protection level of the most sensitive data it holds. Averaging or weighting by access frequency would leave the prescription records protected below their own level.
A hotel booking group's external security audit is six weeks away. Which two things should the security test team do now so that its work will be usable as audit evidence?
Re-run the complete regression suite during the audit window so that the auditors can observe every single test being executed in front of them.
Observing execution is theatre rather than evidence, and it consumes the audit window. Auditors sample recorded results instead.
Keep the test results traceable to the control that each one exercised, so an auditor can see which requirement a given result speaks to.
Correct. Without that link the auditor cannot tell whether a passing result says anything about the control under examination.
Hand the auditors direct write access to the defect tracker so that they can close the findings they consider to have been adequately resolved.
Closing findings is the organisation's responsibility. An auditor who performs the remediation loses the independence the audit depends on.
Retain the evidence of how each result was produced, including environment and configuration, so a finding can be reproduced and dated.
Correct. A finding without its conditions cannot be re-established, so the audit cannot confirm it or judge whether it is still current.
Delay reporting newly found weaknesses until after the audit, so that the audit sees a stable picture of the control set as it stands.
Withholding findings misrepresents the security state and is the kind of behaviour the audit exists to detect.
An audit weighs evidence against a defined reference, so what it needs from testing is traceability and reproducibility: which control each result speaks to, and enough record of how the result was produced for it to be re-established later.
A smart-building platform controls heating and door access in 60 office buildings and is built around a widely used open-source message broker. What does the use of that open-source component mean for security testing?
Review by a large community lowers the residual risk in the component, so the available test effort is better spent on the application code written in-house.
Community review raises the chance a flaw is found, not the chance it is absent. Widely used components are attractive targets precisely because one flaw reaches many installations.
The open-source licence passes responsibility for defects to the maintainers, so handling the component's vulnerabilities falls outside the scope of the test team.
Open-source licences typically disclaim warranty rather than transfer responsibility. The organisation that ships the component carries the risk of the vulnerability in its product.
The component carries publicly documented vulnerabilities, so its version is inventoried and checked against vulnerability data before and after release.
Correct. Known flaws in a known version are the cheapest attack available, which is why the syllabus asks for an inventory and for continuing comparison against vulnerability sources.
The component is compiled together with the application, so a successful build is evidence that no version with a known vulnerability is in use.
A build checks that the code compiles and links, not whether the resolved version appears in a vulnerability database. That comparison is done by composition analysis.
Open-source components bring published source and published vulnerabilities. The syllabus treats the inventory of such components and the continuous comparison of their versions against vulnerability data as part of the security tester's work, both before release and during operation.
A payroll bureau states that it has implemented zero trust because every employee now reaches the internal systems through a VPN with multi-factor authentication. Which statement identifies the gap in that claim?
Multi-factor authentication is a user-facing control whereas zero trust is concerned with the strength of encryption in transit, so the two address different problems entirely.
Zero trust is about where trust is placed, not about cipher strength. Strong authentication is part of it; the gap lies in what happens after the user is authenticated.
Zero trust applies to machine-to-machine traffic between internal services, so controls placed on human users have no bearing on whether the paradigm has been adopted.
The paradigm covers every subject that requests a resource, human or service. Restricting it to service-to-service traffic describes one application of it, not its scope.
Once the tunnel is established the user is implicitly trusted for everything behind it, whereas zero trust authorises each request to a resource.
Correct. The VPN grants a position inside the perimeter; zero trust assumes no such position confers rights and re-evaluates every request against least privilege.
A VPN concentrator terminates outside the data centre, so zero trust can be claimed once the tunnel is terminated on the application server itself instead.
Moving the tunnel endpoint changes the topology, not the trust model. The user would still be implicitly trusted for everything that endpoint can reach.
Zero trust removes implicit trust based on network location. A VPN does the opposite: it establishes a trusted position once, from which the user reaches whatever the network allows. Per-request authorisation against the individual resource is what the paradigm requires.
A drone delivery operator runs its build pipeline on shared agents. Each agent authenticates to the internal artefact repository with one service account that can read every artefact the company publishes. Which test best checks whether the zero trust paradigm has been applied here?
Scan the build network from an address outside it and check that the artefact repository answers on no unexpected port, confirming that the segment boundary still holds.
This tests perimeter segmentation, which is the model zero trust replaces. The weakness here is inside the boundary, where one account reads everything.
From a build agent, request artefacts the running pipeline has no declared need for, and check each request is authorised against that pipeline's own entitlement.
Correct. This exercises per-request authorisation and least privilege for the pipeline as a subject, which is exactly what the shared broad-read account violates.
Verify that the service account's password satisfies the length and complexity rules set out in the organisation's password policy and that it is rotated on the defined schedule.
A strong, rotated credential still grants the same excessive read scope. Credential hygiene is worth testing, but it does not address the implicit trust being questioned.
Verify that the artefact repository endpoint negotiates a current TLS version and rejects every cipher suite that the organisation has placed on its deny list this year.
Transport protection prevents interception; it says nothing about whether an authenticated agent should have been allowed to fetch the artefact in the first place.
Applying zero trust to a build pipeline means each pipeline is a subject whose requests are authorised individually against least privilege. The test that exercises that is one that asks for artefacts outside the running pipeline's declared need and checks the request is refused.
Chapter 2 · Security Test Techniques — 7 questions
A security test engineer is given a compiled binary of a port terminal's gate controller and network access to a test instance, but no source code, no design documents and no account on the build system. Which classification fits the testing that can be performed?
White-box testing, because the binary can be disassembled and the resulting instructions are a representation of the program's internal structure.
Disassembly is reverse engineering performed without the design knowledge white-box testing assumes. The syllabus classes work from a delivered artefact without internal documentation as black-box.
Grey-box testing, because having network access to a running instance already constitutes the partial internal knowledge that defines the grey-box approach.
Grey-box means partial knowledge of the internal structure, such as a data model or an architecture diagram. Network reachability is how any external user interacts with the system.
Black-box testing, because the tester works from the externally observable behaviour of the running system without visibility of its internal structure.
Correct. No source, no design and no build access leaves only the external interfaces, which is precisely the black-box position.
Static testing, because a binary artefact is examined as a delivered object rather than exercised through its interfaces while it is running.
Static and dynamic is a different axis, and the scenario gives network access to a running instance, so the system is intended to be executed during the testing.
The black / white / grey-box classification rests on how much internal knowledge the tester has. With no source, no design and no build access, the tester works from externally observable behaviour, which is black-box. The separate static / dynamic axis describes whether the system is executed.
Before any environment is deployed, a hotel booking group reviews the infrastructure-as-code templates that define its booking cluster, looking for over-permissive network rules and hard-coded secrets. How is this activity classified?
Dynamic security testing, because the templates describe running infrastructure and the findings concern how that infrastructure will behave at runtime.
What the artefact describes does not determine the classification; whether the system is executed does. Nothing is deployed, so nothing is observed in execution.
Static security testing, because the artefacts that define the system are examined without the system described by them being executed.
Correct. Reviewing code or configuration without running it is static testing, and infrastructure definitions are a legitimate static test object.
Penetration testing, because the activity searches for the misconfigurations that an attacker would use to gain a foothold in the booking cluster.
A penetration test attempts to exploit a live target. Here nothing is attacked and nothing is running; only the definition is read.
Destructive testing, because a finding in a template invalidates the whole environment that would otherwise have been built from that template.
Destructive testing deliberately damages or disables a running test object to observe the result. Rejecting a template is a review outcome, not destruction.
Static security testing examines artefacts without executing the system they describe. Infrastructure-as-code templates are such artefacts: the review finds over-permissive rules and embedded secrets before any resource exists.
At a port terminal gate, a truck driver's badge number is read from the card, the driver then enters a PIN, and the system finally decides which lanes that driver may use. Which mapping of these three steps is correct?
Reading the badge number is authentication, entering the PIN is identification, and deciding the permitted lanes is the authorisation of the session.
The two first steps are swapped. A badge number is a claimed identity that anyone could copy; the PIN is the secret that proves the claim.
Reading the badge number is identification, entering the PIN is authorisation, and deciding the permitted lanes is the authentication of the driver.
Entering a secret proves identity rather than granting rights, and the lane decision grants rights rather than proving identity, so the last two are swapped.
Reading the badge number is identification, entering the PIN is authentication, and deciding which lanes may be used is the authorisation decision.
Correct. Claim, proof, permission: this is the order the syllabus uses, and each step is a separate test target.
Reading the badge number is authorisation, entering the PIN is authentication, and deciding the permitted lanes is the identification of the vehicle.
Reading an identifier grants nothing, and a lane decision identifies nobody. Only the middle step is placed correctly here.
Identification claims who the subject is, authentication proves the claim, and authorisation decides what the proven subject may do. The badge number is the claim, the PIN is the proof, the lane decision is the permission.
A payroll bureau performs two recurring activities on its identity data. Which two statements correctly describe reconciliation testing and recertification testing as the CT-STE syllabus uses those terms?
Recertification is the planned renewal of the TLS certificates used by the identity provider before they expire, which keeps the login flow continuously available.
This confuses the word certificate with the word certification. Recertification concerns the re-approval of access rights, not the lifecycle of cryptographic certificates.
Reconciliation compares the accounts and permissions present in the system against the authoritative source and reports every difference that is found.
Correct. Orphaned accounts and permissions that exist in the system but not in the source of truth are exactly what reconciliation is designed to surface.
Reconciliation re-runs the password policy against every stored account and forces a change where the stored hash no longer satisfies the current rules.
That is a password policy enforcement exercise. Reconciliation is about the existence and scope of accounts and permissions, not about credential strength.
Recertification requires the responsible owner to re-approve each identity's access at defined intervals, so entitlements no longer needed are withdrawn.
Correct. Periodic re-approval by the accountable owner is what prevents the slow accumulation of rights as people change roles.
Recertification measures the elapsed time between an employee leaving and their accounts being disabled, and reports the median figure for the period.
That is a useful leaver metric, but it measures one process rather than re-approving the access that remains in place for current staff.
Reconciliation compares what the system holds against the authoritative source and reports the differences. Recertification is the periodic re-approval of each identity's access by the responsible owner, so that entitlements which are no longer justified are withdrawn.
A payroll bureau transfers salary files to a bank each month and stores the same files for seven years. The security test is to confirm that the data is protected at rest and in transit. Which set of checks matches that objective?
Confirm the batch user holds the read and write rights it needs on the transfer directory and that those rights are reviewed and re-approved by the application owner each quarter.
Access control on the directory is worth testing, but it is an authorisation concern. It says nothing about whether the content itself is protected at rest or on the wire.
Confirm the checksum calculated before the transfer matches the checksum calculated by the bank after it, so that the file is known to have arrived without corruption.
A checksum detects accidental corruption and, unsigned, can be recomputed by anyone who altered the file. It is an integrity aid, not protection of the data.
Confirm the stored files are encrypted with managed keys, the transfer channel is protected, and the data is not written in clear text to logs or temporary files.
Correct. This covers both states the objective names and the common leak paths where protected data reappears unprotected.
Confirm the bank returns its acknowledgement message inside the agreed service window and that a missing acknowledgement raises an alert for the operations team.
This checks the reliability of the interface and its monitoring. Timeliness of an acknowledgement is unrelated to the confidentiality of the payload.
Protection at rest and in transit covers the stored artefact, the transfer channel and the places data leaks out of both: logs, temporary files and exports. Access rights, checksums and acknowledgement timing address other quality concerns.
A drone delivery operator has hardened the operating system of its ground stations: unused services are stopped, default accounts are disabled and remote shell access is restricted to one management network. What does a security test of that hardening consist of?
Checking on the running system that each measure is in effect and that the disabled services and accounts cannot be brought back through an exposed interface.
Correct. The test target is the actual state of the deployed station plus the paths by which that state could be reverted at runtime.
Checking that the hardening checklist has been signed off by the platform owner and that the version applied matches the one named in the release notes.
This is documentation review. A signed checklist is evidence of intent, not evidence that the service is actually stopped on the station in the field.
Checking that the ground station reboots within the agreed time once the hardening is applied, since availability is the dominant quality characteristic here.
Restart time is an availability measure. It does not establish whether the hardening measures themselves hold after the station comes back up.
Checking the hardening script into version control and running a static analysis of it, because the script is the artefact that defines the resulting configuration.
Static review of the script is useful and cheap, but a script can fail silently or be overridden later. The syllabus expects the deployed state to be verified.
Hardening is a claim about the state of a running system. Testing it means verifying on the running system that each measure is actually in effect, and that an exposed interface cannot undo it by restarting a service or re-enabling an account.
A freight rail operator's security risk analysis ranks one risk highest: a partner could modify another partner's wagon-load data through the consignment API. Which test design addresses that risk most directly?
Run a full-protocol fuzzing campaign against every consignment API endpoint and record each input that causes the service to crash, hang or return an unexpected error.
Fuzzing looks for robustness failures in input handling. It can find other defects, but it does not exercise the authorisation decision that the stated risk depends on.
Scan the hosts behind the consignment API for missing operating system patches and rank the findings by the severity score the scanner assigns to each one.
Patch state matters for a different class of risk. A fully patched host will still allow the write if the API authorises it.
Using a partner token scoped to read, attempt write operations on load data, including consignments of another partner, and check each attempt is refused.
Correct. This exercises both the scope enforcement and the tenant separation that the highest-ranked risk would breach.
Review the API gateway's TLS configuration and confirm the cipher suites in use are those that the operator's cryptography standard currently permits.
Transport security protects the request in flight. The stated risk concerns what an authenticated partner is permitted to do once the request arrives.
The risk is a horizontal authorisation failure combined with a scope violation. The test that addresses it uses a legitimately issued read-scoped token and attempts the forbidden writes, including writes against another partner's data.
Chapter 3 · The Security Test Process — 5 questions
During a security test of a museum ticketing platform, the team identifies a risk it cannot mitigate within the release. Who decides whether that risk is accepted, and what is the test engineer's part in that decision?
The security test engineer decides, because the risk was found during testing and the engineer understands its technical nature better than anyone else.
Technical understanding is necessary for describing the risk but not sufficient for accepting it. Acceptance commits the organisation to a consequence the engineer does not own.
The scoring tool decides, because a score below the agreed threshold constitutes acceptance and a score above it constitutes rejection of the risk.
A score is an input to prioritisation. Thresholds can guide a decision but cannot replace the accountable person who carries the residual risk.
The stakeholder accountable for the asset decides, and the test engineer supplies the technical evidence on which that decision is based.
Correct. The syllabus separates the roles: testing produces evidence, the business owner of the asset decides on treatment or acceptance.
The external auditor decides, because acceptance of a residual risk has to be recorded by a party independent of the development organisation.
An auditor checks that acceptance was decided and recorded by the right person through the right process; the auditor does not take the decision.
Risk acceptance is a business decision and belongs to the stakeholder accountable for the asset. The security test engineer's responsibility is to describe the risk accurately: what can happen, how it was demonstrated and what the technical impact would be.
A museum ticketing platform goes live in two days. There is no documented threat model and no security risk analysis, and one tester is available for the two days. Which approach fits the situation best?
A full scripted security test suite covering every chapter of the applicable standard, so that the coverage achieved can be reported precisely afterwards.
Writing and running that suite takes far longer than two days. The result would be a small, arbitrary fragment of the suite rather than precise coverage.
Time-boxed exploratory security testing guided by known attack patterns, with a record of what was covered so the remaining gaps stay visible.
Correct. Exploratory testing is the syllabus's answer when the test basis is thin, and the coverage record keeps the result honest.
Postponing security testing to the first maintenance release, by which time the threat model and the risk analysis will have been produced properly.
The platform is exposed from go-live. Deferring the work leaves the launch period, when attention is highest, entirely untested.
A performance test of the ticketing flow, because an overload at opening time is the most probable failure a system of this kind will encounter.
Overload is a real risk, but it answers a different question. Substituting performance testing leaves the security objective unaddressed.
When the test basis is missing and the time box is fixed, exploratory security testing guided by known attack patterns gives the most information per hour. Recording what was covered turns the remaining gaps into a visible, reportable result.
A smart-building platform is setting up an environment for its security tests. Which property of that environment matters most for the validity and the safety of the results?
It holds an unmasked copy of the live tenant data, so that the test results reflect exactly the data an attacker would encounter in the production platform.
Copying live personal data into a less protected environment creates the very exposure the testing is meant to prevent, and in many jurisdictions breaches data protection law.
It is shared with the performance test team, so that security findings can be correlated with the load profile that happened to be running at the time.
Sharing makes both sets of results harder to attribute, and concurrent load changes the behaviour a security test is trying to observe.
It reproduces the security-relevant configuration of production while staying isolated, so findings transfer and test attacks cannot reach live buildings.
Correct. Representativeness makes the findings meaningful; isolation makes the testing safe to perform. The syllabus names both as characteristics of an effective environment.
It runs with logging switched off, so that the volume of noise generated by the security tools does not obscure the application's own behaviour during a run.
Logging is itself a test object: a security test needs to confirm that attacks are recorded. Disabling it removes evidence rather than noise.
An effective security test environment is representative and isolated at the same time: representative so that findings transfer to production, isolated so that attack traffic and destructive tests cannot reach live systems, live data or real users.
A port terminal system is split into a gate controller, a yard-planning service and a billing service, which exchange messages over an internal bus. Which security test belongs at component integration level rather than at component or system level?
Checking that the gate controller's PIN parsing routine handles an input longer than the declared field without writing past the end of its buffer.
This exercises one routine inside one component, with no other component involved, which places it at component level.
Checking that the yard-planning service rejects a message from the gate controller whose sender identity has been replaced with that of billing.
Correct. The test target is the trust relationship across the interface between two components, which is what component integration testing addresses.
Checking that a driver who has completed the full gate-to-billing journey cannot then retrieve the invoice of a different haulage company from the portal.
This follows a complete business flow through the whole system, so it belongs at system level even though several components take part.
Checking that the operating system of the host running the yard-planning service has no services listening on ports outside the approved baseline.
This examines the platform underneath a single component. It is infrastructure hardening verification rather than an interface test between components.
Component integration testing targets what happens between components: the trust each places in messages from the others, and whether that trust is verified. Buffer handling inside one component is component level; an end-to-end business journey is system level.
An online pharmacy states a security requirement: a prescription may be dispensed once, and a dispensed prescription cannot be reused by anyone. Which set of tests covers that requirement across test levels?
A system test confirming that the dispensing screen shows a warning after the first dispense, repeated in each of the branch configurations the pharmacy currently operates.
A warning on a screen is a user-interface behaviour that an attacker bypasses by calling the service directly. It does not establish that the second dispense is refused.
A component test of the prescription identifier generator, confirming that the identifiers it produces are unique across the whole retention period of seven years.
Uniqueness of identifiers is necessary but addresses a different failure. A unique identifier can still be dispensed twice if the state transition is not enforced.
A component test of the dispensed-state transition, an integration test that a second branch's request is refused, and a system test replaying a captured request.
Correct. Each level adds something the others cannot see: the state machine, the cross-branch race, and the replay of a complete request.
An acceptance test in which a pharmacist confirms the wording of the message that appears when a prescription has already been dispensed at another branch.
Wording review improves usability of the message. It does not test whether the system actually refuses the second dispensing attempt.
A requirement of this kind has to be verified where the state is held, where two actors meet, and where a complete attack can be staged. That gives a component test of the transition, an integration test of the second actor, and a system test of a replayed request.
Chapter 4 · Security Testing Standards and Best Practices — 4 questions
A hotel booking group must observe one security standard because its card acquirer requires it contractually, and has adopted a second standard by its own choice. What distinguishes the two in terms of security testing?
Failing the contractually required standard carries legal or commercial consequences, while the voluntarily adopted one shapes good practice without that exposure.
Correct. The difference lies in the consequence of a gap, which is what makes the mandatory standard's test conditions non-negotiable in scope.
The contractually required standard applies to the production environment while the voluntary one applies to the test environments that the group operates.
Neither kind of standard is scoped by environment in this way. Both can carry requirements for production and for the environments used to build and test it.
The contractually required standard is verified by an external auditor and the voluntary one by the test team, so the form of the evidence produced differs.
Who verifies is a separate decision. A voluntary standard can be externally certified, and a contractual one can be evidenced by internal testing.
The contractually required standard prescribes test techniques and the voluntary one prescribes acceptance criteria, so together they cover different parts of the test process.
The split is not by content type. Standards of either kind may carry controls, techniques and criteria; the difference is whether applying them is obligatory.
The syllabus separates mandatory from voluntary application of standards. A mandatory standard is imposed by law, regulation or contract, so a gap has legal or commercial consequences; a voluntary one informs good practice and is applied at the organisation's discretion.
A smart-building platform's composition analysis reports three things about a…
A smart-building platform's composition analysis reports three things about a logging library: the general class of flaw is improper neutralisation of user-supplied input written into a log message; the specific flaw in that library version has its own published identifier; and there is a documented pattern describing how attackers exploit flaws of this kind. Which catalogues correspond to these three, in that order?
CVE for the weakness class, CWE for the identified flaw in that library version, and CVSS for the documented attack pattern used against it.
CWE and CVE are swapped here, and CVSS scores a vulnerability's characteristics rather than describing an attack pattern.
CAPEC for the weakness class, CVE for the identified flaw in that library version, and CWE for the documented attack pattern used against it.
Only the middle element is right. CAPEC describes attack patterns, not weakness classes, and CWE describes weakness classes, not attacks.
CWE for the weakness class, CVE for the identified flaw in that library version, and CAPEC for the documented attack pattern used against it.
Correct. This is the weakness, vulnerability, attack chain exactly as the syllabus presents it.
CWE for the weakness class, CVSS for the identified flaw in that library version, and CAPEC for the documented attack pattern used against it.
The first and third are right, but a CVSS score is attached to a vulnerability; the identifier of that vulnerability is the CVE.
The syllabus describes the chain weakness, vulnerability, attack. CWE catalogues weakness classes, CVE identifies a concrete vulnerability in a concrete product version, and CAPEC catalogues the attack patterns used against them. CVSS is a scoring scheme, not a catalogue of entries.
A port terminal is threat modelling its gate release system with STRIDE. Two…
A port terminal is threat modelling its gate release system with STRIDE. Two concerns are raised: a haulier could later deny having collected a container, and a gate operator could obtain the yard supervisor's functions. Which two STRIDE categories, with their matching test ideas, apply to these concerns?
Tampering — test that the container weight recorded at the gate cannot be modified while it is in transit between the gate and the yard system.
Tampering is a genuine STRIDE category and a sensible test, but neither concern in the scenario is about altering data in flight.
Repudiation — test that each release action is logged with an identity that the actor cannot alter or remove afterwards.
Correct. Non-repudiation rests on an audit trail the actor cannot change, so the test targets exactly that property.
Information disclosure — test that a haulier cannot read the consignment details belonging to a different haulage company through the portal.
A valid test, but reading another party's data is a confidentiality concern rather than denial of an action or gain of rights.
Elevation of privilege — test that an operator session cannot invoke supervisor functions by calling their endpoints directly.
Correct. Hidden menu items do not constitute authorisation, so the test calls the privileged endpoints with the lower-privileged session.
Denial of service — test that the gate release service continues to answer while a large volume of requests arrives from one source.
Availability matters at a terminal gate, but the two concerns raised describe accountability and privilege, not loss of service.
Denying an action that was performed is repudiation; obtaining rights belonging to a higher role is elevation of privilege. The other STRIDE categories are real and testable, but they do not describe the two concerns raised here.
A hotel booking group is about to security test a new loyalty API. The requirement specification describes the business rules in detail but says nothing about security. Which approach derives a usable test basis?
Test the functional requirements that exist, and record that security could not be tested because the specification provides no basis on which to design the tests.
A missing specification is a defect to report, not a reason to skip testing. Recognised practice supplies a serviceable basis in the meantime.
Ask the development team which security controls they implemented and limit the test conditions to confirming that those controls behave as they described.
This makes the implementation its own oracle. Controls that should exist but were never built would never be tested, which is the gap that matters most.
Derive test conditions from the OWASP API security risks and the control set of the standard the group has adopted, and raise the silent requirements as defects.
Correct. Recognised practice gives an independent test basis, and reporting the gap gets the specification fixed for the next release.
Run the organisation's standard scanner against the API and treat whatever the tool reports as the complete set of security test conditions for this release, since the tool encodes current practice.
A scanner finds a subset of technical issues and cannot see business logic flaws such as a loyalty balance that can be transferred twice.
Where requirements are silent, the syllabus has the tester fall back on recognised practice: the relevant OWASP risk list and the control set of the standard the organisation has adopted become the test basis, and the silence in the specification is itself reported as a requirement defect.
Chapter 5 · Adjusting Security Testing to the Organizational Context — 4 questions
A payroll bureau has no central security function. Each of its nine product teams organises its own security testing. What is the main consequence for security testing, and what compensates for it?
Security testing becomes faster in every team; a central reporting line is added so that management retains a single consolidated view of the open findings.
Proximity can speed up feedback, but speed is not the main consequence, and consolidated reporting does nothing about uneven depth between the teams.
Coverage and depth vary between teams; a shared standard, common tooling and cross-team review of findings bring the results back to a comparable level.
Correct. Variation in capability is the characteristic weakness of a decentralised structure, and shared baselines are the standard countermeasure.
Security testing loses its independence inside every team; an external provider is therefore engaged to repeat the tests that the teams have already performed.
Reduced independence is a real concern in embedded models, but paying an external party to duplicate the same tests addresses neither independence nor the coverage gaps.
Security testing becomes cheaper in every team; a shared budget is introduced so that the teams working on the highest risks receive the larger share of it.
Decentralisation tends to duplicate effort rather than reduce cost, and the budget mechanism described leaves the differences in capability untouched.
A fully decentralised structure puts security testing close to the product but makes depth and coverage depend on each team's skill and appetite. The usual compensation is a shared minimum standard, common tooling and cross-team review so results stay comparable.
Data protection regulation obliges an online pharmacy to erase a customer's personal data on request. How does that regulatory obligation turn into security testing?
Test that the erasure request form is reachable from the customer account page and that submitting it returns a confirmation message inside the published response period.
This checks that the front end works. It says nothing about whether the data was removed or whether someone else could submit the request.
Test that the erasure job runs inside the maintenance window and that its failure is reported to the operations team through the standard alerting path.
Operational monitoring of the job is worth having, but a job that runs successfully can still leave copies behind in exports and secondary stores.
Test that an accepted request removes or anonymises the data in every store covered by the retention rules, and that nobody can trigger it for another person's record.
Correct. Completeness of the erasure and authorisation of the request are the two testable properties the obligation implies.
Test that the privacy notice names the legal basis for processing and that its text matches the version the data protection officer has formally approved.
Document review belongs to compliance work. It verifies what the pharmacy says it does, not what the system actually does with the data.
A regulatory obligation becomes a test condition with two sides: that the required effect actually occurs everywhere the data lives, and that the mechanism itself cannot be abused by someone acting against another person's record.
A port terminal reconstructs an incident. A caller claiming to be from the…
A port terminal reconstructs an incident. A caller claiming to be from the badge-printing supplier persuaded a gate clerk to read out the format of internal employee numbers. Two days later a visitor without an appointment entered the administration building behind a group returning from lunch. The same afternoon a USB stick was found plugged into an unattended workstation in the planning office. Three days after that, a planning account was used at 03:10 to export the full container manifest. Which two conclusions does this evidence support?
The first two steps are social engineering — vishing then tailgating — and belong to the attacker's information gathering and access phase rather than to the exploit.
Correct. Both obtain information or physical presence without touching the system, which is exactly how the syllabus describes the preparatory phase.
The USB stick shows the attacker had physical access to the server room, so the segmentation between the office network and the operational systems is the control that failed.
The stick was found in the planning office, not the server room, and nothing in the evidence shows a crossing between network segments.
The manifest export is the objective of the chain, so the tests with the highest value are those on the controls between workstation access and bulk data export.
Correct. Analysing where the chain was heading is what turns an incident into test priorities, and the last hop is where the damage is realised.
The 03:10 timestamp establishes that the account was used from outside the country, so the test priority is the geographic restriction placed on remote access.
A night-time timestamp establishes a time, not a location. Drawing a geography conclusion from it would send the testing after the wrong control.
The sequence is an opportunistic, scanner-driven attack against the perimeter, so the appropriate response is to re-run the external vulnerability scan at a higher frequency.
Opportunistic attacks do not involve a targeted phone call and a physical entry. The evidence describes a deliberate, staged campaign against this terminal.
The chain runs social engineering by telephone, physical tailgating, a dropped device for a foothold, and finally the bulk export. The first steps are reconnaissance and access; the export is the objective, which is where the highest-value controls and tests sit.
A hotel booking group's monitoring shows the following over eleven weeks: an…
A hotel booking group's monitoring shows the following over eleven weeks: an administrator account dormant for fourteen months was used again, each time between 02:00 and 04:00; outbound DNS queries from one reporting server grew from about 400 to about 9,000 per night, each carrying a long sub-domain label; no file on that server was modified; and no ransom demand or defacement occurred. Which two conclusions does this pattern support?
The absence of modified files shows the attacker lacked write permission, so the test priority is the integrity controls on the reporting server's own file system.
An attacker whose objective is to copy data has no reason to write. Absence of modification is consistent with exfiltration rather than evidence of a missing privilege.
The DNS pattern with long labels and a steady nightly volume is consistent with data being carried out over a channel that is usually permitted outbound.
Correct. Encoding payload into sub-domain labels is a recognised exfiltration technique precisely because DNS is rarely filtered on content.
The absence of a ransom demand indicates an automated commodity attack, so the appropriate response is to raise the frequency of the anti-malware signature updates.
Quiet, prolonged activity with no demand points the other way: towards a patient operator whose goal is continued access rather than an immediate payout.
The reactivated dormant account points at a weakness in the periodic review of entitlements, which is the control that recertification testing is meant to catch.
Correct. An account unused for fourteen months should not have survived a recertification cycle, so the review control is a direct test target.
The nightly window shows the activity was performed by an internal employee, so the test priority is the segregation of duties inside the reporting team.
Night-time activity suits an attacker avoiding observation at least as well as an insider. The timing alone does not identify who was at the keyboard.
Long sub-domain labels in a steadily rising volume of outbound DNS is the classic shape of data leaving over a protocol that firewalls rarely block. The reawakened dormant account points at entitlement review, which is what recertification testing exists to check.
Chapter 6 · Adjusting Security Testing to Software Development Lifecycle Models — 4 questions
A freight rail operator develops its consignment platform in a sequential lifecycle with one release a year and a single test phase shortly before go-live. How does that model affect security testing?
Security findings surface evenly across the year, because the long analysis phase gives the test team time to prepare and review its cases well before any code is available.
Preparation can start early, but findings require something to test. With a single late execution phase the findings themselves still arrive at the end.
Security findings surface early, because a sequential model requires every security requirement to be agreed and signed off before implementation can begin.
Signed-off requirements describe intent. Whether the implementation honours them is unknown until it is tested, which in this model happens late.
Security findings surface late, when changing the design is expensive, so threat modelling and static analysis during design and coding are needed to shift them earlier.
Correct. The cost-of-change curve is the characteristic problem of the sequential model, and shift-left activities are the syllabus's countermeasure.
Security findings carry less weight, because a yearly release gives the operations team time to put compensating controls in place before the following release.
A long gap between releases means a defect stays in production longer, which raises its weight rather than lowering it.
In a sequential model the dynamic test phase sits at the end, so architectural security defects surface when redesign is costly and the release date is close. The syllabus's answer is to shift security work left: threat modelling during design, static analysis during coding.
A smart-building platform has run in production for three years with no change to its own code. Why does its security status still need re-assessment during operation?
Deployed software degrades as its storage media age, so periodic re-testing is needed in order to detect the resulting corruption of the installed binaries.
Media integrity is an infrastructure concern handled by checksums and backups. It is not the reason the syllabus gives for re-assessing security during operation.
Operational logs accumulate until they fill the available disk, so the re-assessment is in practice a capacity review of the hosting platform underneath.
Disk exhaustion is an availability risk worth monitoring, but it does not describe why the security posture of unchanged software changes over time.
Users acquire habits that bypass the intended workflow, so the re-assessment measures the gap between the documented process and actual usage patterns.
Workaround behaviour is a genuine risk source, yet it concerns process rather than the technical security status of the deployed system.
New vulnerabilities are published for components that did not change, so a system whose own code is untouched can become exposed over time.
Correct. The known-vulnerability landscape moves even when the product does not, which is why operation and maintenance includes periodic re-testing.
Security status is relative to what is known about the components and the threat landscape, both of which change while the software stands still. New vulnerabilities published for unchanged third-party components are the common case.
A freight rail operator replaces the consignment API's shared API key with OAuth client credentials. Nine partner integrations use the API: three were changed for the new mechanism, six were not. Which combination of confirmation and regression testing fits?
Confirm the new mechanism on the three changed integrations and leave the six untouched ones out of scope, because no change was made to their own code or configuration files.
Their code did not change, but the authorisation mechanism they relied on did. That is exactly the situation regression testing exists to cover.
Regression test the nine integrations without any confirmation testing, since a successful regression run already demonstrates that the change works the way it was intended to.
Regression shows nothing broke. It does not establish that the new mechanism enforces what the old one did, which needs its own targeted confirmation.
Confirm the new mechanism on the three changed integrations and regression test the authorisation paths of all nine, as the six untouched ones also relied on the old one.
Correct. This covers both the intended effect of the change and the collateral risk to the integrations that were not modified.
Confirm the new mechanism on one representative integration and treat the remaining eight as covered, because they all call the same endpoint in the same way with the same payload.
Integrations differ in the scopes they request and the data they reach. A single sample would miss precisely the partner whose entitlement was mapped wrongly.
Confirmation testing verifies that the change does what it was meant to do. Regression testing covers what might have been disturbed, and here the untouched integrations were authorised by the mechanism that has just been replaced, so they are squarely in scope.
An online pharmacy moves from four releases a year to continuous delivery, with up to twelve deployments a day. Its regulator still requires a signed security test report for every release that reaches patients. Which two analyses of the impact on security testing are sound?
Security activities that used to take days per release have to run inside the pipeline as automated gates, with the slower manual work scheduled on a separate cadence.
Correct. Splitting the work by how long it takes is the standard adaptation: fast automated checks per deployment, deeper assessments on their own rhythm.
Continuous delivery removes the regulator's basis for requiring a report, since there is no longer a release boundary at which such a report could be prepared and issued.
Each deployment that reaches patients is a release in the regulator's sense. Changing the delivery mechanism does not change the obligation.
The report has to be produced from evidence the pipeline emits for each deployment, so the reporting obligation becomes a requirement on the pipeline's own output.
Correct. Evidence generation becomes a design requirement for the pipeline, otherwise there is nothing to sign at deployment number twelve.
The deployment frequency means that a full penetration test has to be repeated before each of the twelve daily deployments in order to keep the signed evidence current.
A penetration test takes days and cannot run twelve times daily. This is the reasoning that leads teams to abandon the activity rather than reschedule it.
Because each deployment is small, the security risk carried by any single one of them is low enough that threat modelling can be dropped from the process entirely.
Small changes can still alter trust boundaries, and the risk accumulates across twelve deployments a day rather than disappearing with them.
Continuous delivery does not remove the obligation; it changes where the evidence comes from. Fast checks move into the pipeline as gates, slower deep work runs on its own cadence, and the report has to be assembled from what the pipeline records for each deployment.
Chapter 7 · Security Testing as Part of an Information Security Management System — 4 questions
A port terminal's release gate reads: no unresolved findings rated high or critical, and the authentication and authorisation test conditions fully executed. What does that pair of criteria imply for the test approach?
Effort is steered towards producing an agreed severity rating for every finding, because the gate is expressed in severities rather than in test conditions.
The gate names both severities and condition areas. Rating findings is necessary but is an output of testing rather than a direction for the approach.
Effort is steered towards the test levels closest to the user interface, because that is where authentication and authorisation first become visible to a tester.
Both are enforced at the service and data layers as well, and the interesting failures are usually found by bypassing the interface entirely.
Effort is steered to the named condition areas and to closing high findings, and the criteria also define when security testing can be declared complete.
Correct. Acceptance criteria act as both a priority signal and an exit condition, which is the dual role the syllabus describes.
Effort is steered towards automation, because a gate stated in these terms can be evaluated by the pipeline without a tester having to interpret the findings.
Severity and completeness of condition coverage both need human judgement. Automation can support the gate but cannot decide it on these terms.
Acceptance criteria shape both what is tested and when testing stops. Named condition areas pull effort towards them, and a severity threshold determines which findings must be closed before the release can proceed.
A port terminal's information security management system keeps a risk register with one entry per asset. Which output of the security test cycle is the most useful input to that register?
The number of security test cases executed during the cycle, broken down by the test level at which each one was run and by the tester who ran it.
This measures activity. A large number of executed cases is compatible with both a secure and an insecure system, so it supports no risk decision.
Confirmed vulnerabilities with their technical impact and the assets they affect, so that the risk treatment decision can be taken on them.
Correct. These are the three things a risk register entry needs, which is why the syllabus names test results as an ISMS input.
The utilisation of the organisation's security tool licences during the cycle, so that the next renewal can be sized against the actual demand.
Useful for procurement, irrelevant to risk. Licence usage says nothing about the security state of any asset.
The elapsed duration of the security test cycle compared with the duration that was planned for it in the agreed test schedule.
Schedule variance is a project management measure. It informs planning rather than the treatment of any identified risk.
A risk register entry needs the weakness, the asset it sits on and what would happen if it were exploited. Counts of executed cases, licence usage and schedule variance describe the testing effort rather than the risk.
An information security management system needs metrics that say something about the contribution security testing makes. Which two metrics serve that purpose?
The number of security test cases written per tester per week during the period under review, counted across all of the product teams.
This is a productivity figure. Writing many cases against low-risk assets would improve it without improving security at all.
The share of assets at the highest protection level that were covered by security testing during the period.
Correct. It ties coverage to asset criticality, so it shows whether the testing reached what the ISMS cares most about.
The number of tool scans started during the period, counted across every pipeline and every environment the organisation runs.
Scan count measures automation activity. A thousand scans of the same low-risk service move the number without moving the risk.
The median elapsed time from a vulnerability being confirmed to it being closed and retested.
Correct. Exposure window is a risk property, and it shows whether findings turn into fixes rather than into backlog.
The number of employees who attended the security awareness session that was scheduled during the period.
Awareness training is a worthwhile control, but attendance is unrelated to what security testing contributed.
A useful ISMS metric links testing to risk: how much of what matters was actually examined, and how quickly what was found gets closed. Counts of effort, tool runs or attendance measure activity instead.
An information security management system has received findings from one source for two years: a dynamic scanner run against the public web front end. Nothing arrives from the third-party components or from the infrastructure definitions. How should security testing improve the ISMS?
Increase the frequency of the existing scanner run from monthly to weekly, so that the ISMS receives a more current picture of the same public web front end each week.
Fresher data about the same narrow slice. The components and the infrastructure definitions stay invisible however often the scanner runs.
Add new test object types and approaches — composition analysis of components, review of infrastructure definitions — so the ISMS sees risk it cannot see today.
Correct. The syllabus names new test objects, new approaches and improved coverage as the ways testing raises ISMS maturity.
Report the scanner findings on a finer severity scale, so that the ISMS can rank the risks it already receives far more precisely than it is able to do at present.
Better ranking of a biased sample. The ranking improves while the blind spot stays exactly the same size.
Route the scanner findings into the risk register without an intermediate triage step, so that nothing the tool identifies is lost on the way to the ISMS.
Removing triage adds false positives to the register, which tends to reduce trust in it rather than broaden what it covers.
Maturity grows when the ISMS starts seeing risk it previously could not. That means new test object types and new approaches, not more of the same signal at a higher resolution or frequency.
Chapter 8 · Reporting Security Test Results — 3 questions
During a test of an online pharmacy, a tester confirms that changing one number in a URL returns another patient's prescription document. What does the criticality of that result imply for how it is reported?
It is recorded in the defect tracker with the highest severity and included in the end-of-cycle report together with the rest of the findings.
Normal routing delays the response by days while real patient data stays exposed. The severity marking alone does not trigger anyone.
It is escalated at once through the agreed path to the named recipients, and the reproduction detail is restricted to those who need it.
Correct. Speed addresses the exposure, and restricted distribution keeps a working exploit from spreading further than necessary.
It is reported to the development team alone, because the fix is technical and a wider distribution would merely slow the correction down.
A confirmed data exposure may carry notification duties and needs a decision about taking the function offline, which the development team cannot take alone.
It is published to the whole project distribution list, because a finding of this kind needs the broadest possible awareness in order to be closed.
Broad distribution of a working exploit against live patient data increases the exposure rather than closing it.
Criticality drives both the speed and the breadth of communication. A confirmed exposure of patient data is escalated immediately to the agreed recipients, while the reproduction detail is kept to those who need it, because the report itself becomes attack material.
A composition analysis run on an online pharmacy's dispensing service returns…
A composition analysis run on an online pharmacy's dispensing service returns four findings. Finding A: a parsing library, CVSS 9.1, the vulnerable function is not called anywhere in the service. Finding B: a template library, CVSS 7.4, the vulnerable function is reached from the public prescription-upload endpoint. Finding C: a test-only assertion library, CVSS 8.2, used in the test scope and not shipped. Finding D: a logging library, CVSS 5.3, the vulnerable function is reached from an internal batch job. Which finding should be analysed and treated first?
A, because 9.1 is the highest score reported and the score reflects the severity that the publisher of the vulnerability has assigned to it.
Treating the score as the ranking is the error this question targets. Code that is never called cannot be exploited through this service.
B, because the vulnerable code is reachable from an internet-facing endpoint, which makes the risk concrete despite the lower score.
Correct. Reachability from an exposed entry point converts a catalogue entry into an attack path, which is what prioritisation should follow.
C, because an 8.2 finding in a library that the build pulls in has to be removed before the service's dependency list can be considered clean.
A test-scope library is not shipped, so it presents no runtime exposure. It is worth cleaning up, but not ahead of a reachable production flaw.
D, because an internal batch job runs with elevated rights, which makes any weakness that it touches the most damaging of the four.
Elevated rights raise the impact if the flaw is triggered, but the batch job is not exposed externally, so the path to it is much narrower than B's.
A score describes the characteristics of a vulnerability in the abstract. Analysis turns it into risk by adding reachability and exposure: an exploitable path from an internet-facing endpoint outranks a higher score with no path to it at all.
An injection flaw is confirmed in the search parameter of a smart-building platform. The team proposes to add a rule to the web application firewall that blocks the exact payload used in the test, and to close the finding on that basis. How should the security test engineer respond?
The rule is an acceptable closure, because the firewall sits in front of the application and a request carrying the payload cannot reach the vulnerable code.
It stops that payload. Encoding changes, alternative syntax and a different entry path to the same parameter all get around a signature of this kind.
The rule blocks one payload while the flaw remains, so it is a compensating control; closure requires the parameter handling to be fixed and retested.
Correct. This is the hiding versus removing distinction: the symptom is masked, the weakness is untouched.
The rule should be rejected and the finding reopened, because a web application firewall is not a control that the syllabus recognises for injection flaws.
A firewall rule is a legitimate interim measure while the fix is built. What is wrong here is calling it a closure, not using it at all.
The rule is acceptable if the team also raises the logging level on that parameter, so that any further attempt against it is recorded for later review.
Better logging improves detection after the fact. It adds visibility without removing the weakness that makes the attack possible.
The syllabus distinguishes hiding a vulnerability from avoiding or removing it. A signature that matches one payload leaves the defect in place and reachable by a variant, so it is a compensating control, and closure requires the parameter handling itself to be corrected and retested.
Chapter 9 · Security Testing Tools — 3 questions
Two tool categories are being compared. The first identifies the third-party and…
Two tool categories are being compared. The first identifies the third-party and open-source components a build pulls in and matches them against known vulnerability data. The second instruments the running application so that code paths are observed while dynamic tests execute. Which pair of names is correct?
The first is interactive application security testing and the second is software composition analysis of the dependencies present in the running build.
The two are swapped. Composition analysis reads a dependency manifest; it does not instrument anything at runtime.
The first is software composition analysis and the second is interactive application security testing of the instrumented application.
Correct. Dependency inventory against vulnerability data is SCA, and runtime instrumentation during dynamic tests is IAST.
The first is static application security testing of the source tree and the second is dynamic application security testing of the deployed service.
SAST analyses the organisation's own source rather than the dependency list, and DAST observes a running system from outside without instrumenting it.
The first is software composition analysis and the second is static application security testing of the instrumented code at build time.
The first is right. Static analysis examines code without executing it, so it cannot be the technique that observes paths during a dynamic run.
Software composition analysis works on the dependency inventory of a build. Interactive application security testing instruments the running application so that dynamic traffic reveals what happens inside the code, which places it between the static and the purely dynamic approaches.
A drone delivery operator writes its ground-station software in a language that the candidate static analysis tool cannot parse. Which consideration should decide the selection?
Whether the tool is the one most widely adopted across the industry, since broad adoption is evidence that its rule set is mature and well maintained.
Maturity matters, but a mature rule set for languages the team does not use produces no findings on this codebase.
Whether the tool integrates with the issue tracker already in use, since handling the findings is where most of the effort in a tool rollout goes.
Integration genuinely reduces friction. It is a secondary consideration once the tool can analyse the code at all.
Whether the tool supports the technologies in use, since a tool that cannot read the code will produce no findings on it whatever else it offers.
Correct. Technology fit is the gating consideration; the remaining criteria only start to matter after it is satisfied.
Whether the tool's licence allows an unlimited number of scans, since the pipeline is expected to run it on every commit pushed to the main branch.
Licence terms shape how often the tool can run. Running an unsupported analyser more often still yields nothing on this code.
Among the selection considerations the syllabus lists, fit with the technologies actually in use comes first, because every other property of the tool is irrelevant if it cannot read the artefacts it is bought to examine.
A payroll bureau has the source code for its own services, no source for a purchased tax-calculation engine, and a pipeline that must stay under ten minutes per commit. Which two tool applications fit these constraints?
Static analysis on the in-house code at each commit, with the rule set reduced to the checks that complete inside the time budget.
Correct. The source is available and trimming the rule set is the usual way to make static analysis fit a short pipeline window.
Static analysis on the tax-calculation engine at each commit, so that the purchased code receives the same depth of inspection as the in-house code.
Static analysis needs source, and the bureau does not have it for the purchased engine. Equal depth is not available on these terms.
Dynamic analysis against the deployed tax-calculation engine in a nightly run, since its behaviour can be examined without access to its source.
Correct. Dynamic testing is the approach that works on a closed component, and a nightly schedule keeps it out of the ten-minute window.
Interactive analysis on the in-house code at each commit, because instrumentation adds no measurable time to the duration of a pipeline run.
Instrumentation and the dynamic tests it depends on both cost time, which is the constraint the scenario puts under pressure.
Composition analysis of the in-house code at each commit, so that defects written by the bureau's own developers are matched against vulnerability data.
Composition analysis examines third-party dependencies against published vulnerabilities; it does not evaluate code the team wrote itself.
Tool choice follows what is available and what the budget allows. Source in hand plus a tight time box suits a trimmed static analysis per commit; no source for the purchased engine leaves dynamic analysis, which fits a nightly run rather than a per-commit gate.