ISTQB Specialist (CT-STE v1.0.1) Mock Exam #2 — 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.
A national energy grid operator runs a dispatch control system through which operators issue switching commands to 260 substations in real time. In a security risk workshop the team concludes that if the dispatch console became unreachable for as little as ten minutes, no load-balancing command could be issued at all and the operator would lose control of the network. Which element of the CIA triad is primarily at stake in this scenario?
Availability — authorised operators must be able to reach and use the dispatch function at the moment they need it.
Correct. The stated consequence is that a needed function cannot be used during the outage window, which is exactly the availability property.
Confidentiality — the switching commands and substation states must not be disclosed to anyone outside the control room.
Confidentiality concerns unauthorised disclosure. The scenario says nothing about anyone reading the data; the harm described is that operators cannot act.
Integrity — a switching command must reach the substation exactly as the operator issued it, without alteration.
Integrity concerns unauthorised or undetected modification of data. Here no command is altered; commands cannot be issued at all.
Non-repudiation — it must be provable afterwards which operator issued which switching command.
Non-repudiation is a security property, but it is not one of the three elements of the CIA triad, and the scenario does not describe a dispute over who acted.
Availability is the property that authorised users can access the system and its functions when needed. The scenario describes loss of access to a function, not disclosure of data or unauthorised modification of it.
A telecom operator classifies the data held in its subscriber platform into protection levels. SIM authentication keys are placed in the highest level; marketing contact preferences are placed in the lowest. How does the assigned protection level of an asset influence security testing?
The higher the protection level of the asset, the more rigorous and more extensive the testing of the components that store, transmit or process it.
Correct. Information sensitivity drives the depth, coverage and effort of security testing for the components handling that information.
The protection level selects which cryptographic algorithm the platform must use, but it has no bearing on how the platform is tested.
Classification does influence protection mechanisms, but it also drives test rigour; treating it as purely a design input leaves the test effort unplanned.
Once the subscriber platform as a whole has been classified, every component inside it is tested to the same depth for consistency.
Classification is applied per asset. Components that only touch marketing preferences do not warrant the same test rigour as those handling authentication keys.
The protection level is used after test execution to decide how each reported finding should be labelled in the defect tracker.
Criticality of findings does depend on the asset, but the classification is available before testing and is meant to shape test planning, not only reporting.
The sensitivity of the information determines how rigorous and how extensive the security testing of the components handling it has to be. Classification is an input to test planning, not a label applied afterwards.
A telecom operator is preparing for its annual security audit. Which TWO statements correctly describe the relationship between security testing and a security audit?
Security testing supplies objective evidence about whether the specified controls actually work, and the audit weighs that evidence against the applicable requirements.
Correct. Test results are one of the main evidence sources an audit relies on when judging control effectiveness.
An audit assesses conformance of processes and controls against a defined reference, whereas security testing exercises the system in order to reveal weaknesses in it.
Correct. This is the essential difference in purpose: conformance assessment versus weakness discovery through execution.
A security audit makes separate security testing unnecessary, because auditors execute the same test cases as the security test team during the audit.
Auditors sample and inspect evidence; they do not reproduce the test effort. The two activities have different objectives and both are needed.
Security testing decides whether the organisation passes and is certified, while the audit is limited to reviewing that documentation exists.
The pass judgement belongs to the audit, and audits examine controls in operation rather than documentation alone. The roles are inverted here.
The scope of the audit is derived from the defects that security testing has already found, so audit planning must wait for the test report.
Audit scope comes from the applicable requirements and the audited processes. Test findings inform the audit but do not define its scope.
An audit assesses conformance of processes and controls against a reference; security testing exercises the system and produces the objective evidence about control effectiveness that the audit consumes. Neither replaces the other.
A video streaming provider builds its browser player on an open-source media library that it does not maintain itself. What is the main consequence of this reuse for security testing?
The library's own weaknesses become weaknesses of the player, so both the component and the way the product uses it belong in the test scope, and newly disclosed vulnerabilities in it must be tracked over time.
Correct. Reuse transfers risk into the product, and the disclosure of new vulnerabilities in a widely used component is a continuing trigger for further testing.
Because the source code is public and reviewed by a wide community, the library can be left out of the product's test scope and covered by the community instead.
Public review is no substitute for testing the component as it is configured and used in this product; the provider still carries the risk.
Only the licence terms of the library need to be reviewed, because responsibility for its security stays with the upstream project that publishes it.
Licence review is a different concern, and there is no vendor or upstream project accountable for the risk the provider ships to its own users.
The library may only be exercised with black-box techniques, since the absence of a support contract rules out inspecting or analysing its code.
The opposite is true: the source being available makes static analysis and code review of the component possible in addition to dynamic techniques.
A reused open-source component brings its own weaknesses into the product, so the component and the way the product uses it belong in the test scope, and newly disclosed vulnerabilities in that component must be tracked over the product's life.
An organisation operates a fleet of 180 networked multifunction printers across its offices and is redesigning how those devices are granted access to internal document services. Which design assumption is consistent with the zero trust paradigm?
Each request a device makes is authenticated and authorised on its own merits, whatever network segment the device happens to sit in.
Correct. Removing implicit trust and verifying every request explicitly is the core of the zero trust paradigm.
Devices attached to an internal office VLAN are treated as trusted peers, while devices reaching the service from outside are treated as untrusted.
This is the perimeter model that zero trust is meant to replace: trust is inferred from network location rather than verified per request.
Trust is established once when the device is enrolled into the fleet management console, and that decision then holds for the device's service life.
A permanent trust decision made at enrolment is still implicit trust; zero trust re-evaluates the decision at each access, using current signals.
Only the administrative web interface of a device needs authentication, because submitting a print job is an ordinary business action.
Zero trust does not exempt ordinary business actions; the document flow itself carries the sensitive data and must be verified too.
Zero trust removes implicit trust derived from network location or from a one-off enrolment. Each request is authenticated and authorised on its own merits, every time.
A telecom operator runs two data centres, DC-North and DC-South. Thirty-four backend services — subscriber provisioning, HLR lookup, billing mediation and CDR archiving among them — call each other across a dedicated inter-data-centre link. Today a service accepts an incoming machine-to-machine call as authenticated purely because the source address falls inside 10.42.0.0/16, the range assigned to the peer data centre: no per-service credential, token or client certificate is presented, and any process that can source packets from that range is served. The security architecture board has mandated a move to zero trust and has asked you, as security test engineer, what the test design must now verify. Which test objective follows most directly from applying zero trust to this machine-to-machine communication?
That a service rejects a call arriving from inside 10.42.0.0/16 when it carries no valid per-service identity, and that an authenticated caller is authorised only for the specific operation it requests rather than for the whole API.
Correct. This directly tests that implicit trust from the network range is gone and that each request is verified and least-privilege authorised — the two things zero trust changes here.
That the inter-data-centre link is encrypted end to end and that 10.42.0.0/16 is not routable from the internet, so the perimeter surrounding both data centres is confirmed to be intact.
Both checks are useful hygiene, but they reinforce the perimeter assumption. They would pass unchanged while any process inside the range still gains access without an identity.
That every service can still reach every other service across the inter-data-centre link within the agreed latency budget, so that the newly introduced authentication does not disturb existing connectivity.
Verifying unrestricted reachability is the opposite of the zero trust objective; latency behaviour is also not a security test objective for this change.
That human administrators must complete multi-factor authentication in both data centres before they are permitted to deploy or restart any of the thirty-four backend services.
This tests interactive human access. The risk described is in the service-to-service path, which would remain trusted by IP range even if administrator login were hardened.
Zero trust removes the implicit trust that the source IP range confers. The test must therefore prove that network position alone no longer buys access: a caller from inside the range with no valid service identity is rejected, and an authenticated caller is authorised only for the specific operation it is entitled to.
A tester is given the airline booking API's interface specification and read access to its database schema, but not the service source code. Using that information, the tester attacks the running service through its endpoints. How is this security test best classified?
Grey-box and dynamic: partial internal knowledge is used to design the attacks, and the running service is executed to observe its behaviour.
Correct. Some but not full internal knowledge is grey-box, and executing the deployed service makes the technique dynamic.
Black-box and dynamic: as long as no source code is read, the tester works only from the outside and no internal knowledge is involved.
The schema and interface specification are internal information about the implementation, which is more than a black-box tester would have.
White-box and dynamic: access to the database schema exposes the internal structure of the system, which is what white-box testing means.
White-box implies access to the internal implementation, source code included. A schema alone is partial knowledge, hence grey-box.
Grey-box and static: the test is derived by analysing the specification and the schema, and such analysis work is static by nature.
The grey-box part is right, but the attacks are executed against the running service, so the technique is dynamic, not static.
Partial internal knowledge (interface specification and schema) without full source access is grey-box; exercising the running service makes it dynamic. The syllabus notes that in practice these categories overlap.
An airline's security test plan lists four activities for the passenger booking service. Which one of them is a static security test technique?
Reviewing the authorisation rules in the booking service source code to find code paths where the passenger-to-booking ownership check is missing.
Correct. The work product is examined without being executed, which is the defining characteristic of a static technique.
Sending deliberately malformed request bodies to the running fare-quote endpoint to see whether the parser raises unhandled exceptions.
This executes the deployed service and observes its behaviour, so it is a dynamic technique — specifically fuzzing.
Running an automated vulnerability scan against the internet-facing check-in host to enumerate exposed services and known weaknesses.
A vulnerability scan probes a live target and interprets its responses, which makes it dynamic rather than static.
Submitting a list of five hundred candidate passwords against a valid test account to establish whether the lockout policy triggers.
The credential attempts are executed against the running authentication function, so this too is a dynamic technique.
Static techniques examine the work product without executing it. Reviewing authorisation logic in the source code is static; sending traffic to a running endpoint, scanning a live host and attempting logins are all dynamic.
A telecom operator plans network fuzzing of the protocol handler that receives SIM provisioning messages from its retail channel. Which TWO statements about fuzz testing are correct?
It supplies malformed, unexpected or mutated input — for network fuzzing, deliberately malformed packets — and observes the handler for crashes, hangs and unhandled exceptions.
Correct. This is the technique's definition, and malformed network packets are the syllabus example of network fuzzing.
The value of a campaign depends on being able to detect and diagnose the failures it triggers, so monitoring, logging and crash capture have to be in place before it starts.
Correct. A crash that nobody observes yields no finding, which is why instrumentation of the target is part of preparing the fuzzing run.
A complete formal specification of every valid provisioning message must exist before any fuzzing input can be generated for the handler.
A grammar or sample corpus improves fuzzing efficiency, but mutation-based fuzzing works from captured traffic and needs no complete formal specification.
Fuzzing establishes whether the handler's authorisation rules grant each retail channel role exactly the permissions recorded for that role.
That is an access control test objective. Fuzzing targets robustness of input handling, not the correctness of permission assignment.
Fuzzing results can be reported straight to the developers as exploitable vulnerabilities, because a reproducible crash and a working exploit are the same finding.
A crash shows a robustness defect; whether it is exploitable requires further analysis. Reporting the two as identical overstates the finding.
Fuzzing supplies malformed, unexpected or mutated input — for network fuzzing, deliberately malformed packets — and watches for crashes, hangs and unhandled exceptions. Its value depends on being able to observe and diagnose the failure, so monitoring and crash capture must be in place before the campaign runs.
A telecom operator's identity and access management control is being tested. What does reconciliation testing of identities and permissions verify?
That the identities and permissions actually present in the systems match the authoritative record of who should hold them, exposing entries that exist in one source but not in the other.
Correct. Reconciliation is a comparison between the deployed state and the authoritative source, and its findings are the discrepancies between them.
That every permission currently granted is still required by its holder and has been re-approved by the manager or owner accountable for it.
That describes recertification testing. Recertification asks whether a right is still justified; reconciliation asks whether the two records agree.
That a user holding a valid identity is prevented from carrying out operations beyond the permissions recorded against that identity.
This is an authorisation enforcement test. Reconciliation examines the permission data itself rather than how the system enforces it at runtime.
That the credential policy applied to each identity satisfies the strength and rotation rules written in the operator's security policy.
Credential strength is a separate authentication concern and is not what reconciliation of identities and permissions compares.
Reconciliation compares what actually exists in the target systems against the authoritative record of what should exist, exposing identities and rights present in one source but not the other — for instance orphaned accounts.
In the self-service portal of a telecom operator's billing system, which test targets authorization rather than authentication?
Signing in as a legitimate subscriber and then requesting the monthly invoice belonging to a different subscriber's account number.
Correct. The identity is already established, so what is being probed is whether the system permits this identity to reach another subscriber's data.
Submitting one valid subscriber username together with five hundred candidate passwords to see at which attempt the account is locked.
This attacks the process of proving identity and the protection around it, which is authentication, not authorization.
Presenting a one-time code from an SMS message that expired eleven minutes ago and checking whether the login step still accepts it.
The one-time code is a second authentication factor, so its validity handling is part of authentication.
Checking that the sign-in form returns the same message for an unknown username as for a known username with a wrong password.
This concerns information leakage from the authentication dialogue — account enumeration — and still sits before any permission decision.
Authentication establishes that the claimed identity is genuine; authorization decides what that established identity is permitted to do. Requesting another subscriber's invoice while logged in as oneself probes the authorization decision.
An organisation has hardened its fleet of 180 networked multifunction printers against a baseline: default administrative passwords replaced, unused services such as Telnet and FTP switched off, and firmware signature checking enabled. What is the appropriate objective for a security test of these protective technologies?
Establish that the measures are effective on the deployed devices: that the disabled services no longer answer, that the former default credentials fail, and that unsigned firmware is refused.
Correct. The objective of testing a protective technology is evidence that it actually works in the deployed configuration, not that it was intended.
Establish that the hardening baseline document has been reviewed and formally approved by the manager who owns the printer fleet.
Approval of a document is a governance step. It says nothing about whether the devices in the offices are actually in the hardened state.
Establish that the fleet management console reports the hardening baseline as successfully applied for all 180 devices in its inventory.
This trusts the management tool's own status field. A device can report compliance while a service is still reachable, so the effect must be verified independently.
Establish that the printers have been moved into a separate network zone, since hardening measures only take effect on devices placed behind a firewall.
Zoning is a different protective technology, and hardening works irrespective of zoning. The premise linking the two is wrong.
Testing protective technologies means establishing that the measures are effective on the deployed devices — that the switched-off services really do not answer, that the old default credentials really fail, that unsigned firmware really is refused.
After a restructuring, an airline moved 1,240 employees between departments over one weekend: 610 from ground handling into a new baggage-operations unit, 380 from cargo into ground handling, and 250 from crew scheduling into network planning. Every move was recorded in the HR system, and the provisioning job duly created the role assignments for the new departments in the departure control system, the crew rostering tool and the cargo manifest system. The assignments belonging to the previous departments, however, were not withdrawn. You have been asked to design recertification testing of the resulting access rights. Which test design addresses the risk that these transfers have introduced?
Sample transferred employees for each source-and-target pair, have the accountable role owner re-approve the effective rights each of them now holds across all three systems, and record every right without a current business need — above all a retained right from the previous department — as a failed recertification.
Correct. Recertification re-establishes business justification for the rights actually held, which is exactly what exposes the entitlement left over from the old department.
Confirm for each of the 1,240 employees that the role assignment for the new department was created by the provisioning job and that the employee can now sign in to the system belonging to that new department.
This only proves the additions worked. The accumulated rights from the previous department pass this check untouched, so the actual risk goes undetected.
Re-run the authentication test suite of all three systems against the transferred accounts to confirm that credentials, session handling and multi-factor enrolment survived the mass HR change unaffected.
Authentication was not what the restructuring changed. The transfers altered entitlements, so an authentication regression suite looks in the wrong place.
Compare the total count of role assignments in each of the three systems before and after the weekend and raise a finding whenever the difference does not equal the number of employees who were moved.
Totals can balance out while individuals hold rights they should not, and a count carries no statement about business need, which is the point of recertification.
The risk is accumulated entitlement: transferred staff now hold the rights of both the old and the new department. Recertification testing must have the accountable role owner re-approve the effective rights each sampled person now holds across all affected systems, and must treat any right without a current business need — typically a retained right from the previous department — as a failure.
The security test team for a government tax portal has prepared a plan that includes credential brute-force attempts and fuzzing of the filing endpoint on a pre-production instance. According to the security test process, what has to be in place before execution starts?
Explicit approval from management for the planned intrusive activities, covering the agreed scope, the systems in scope and the time window in which they may be run.
Correct. Security testing may disrupt systems and resemble a genuine attack, so documented management authorisation is a precondition for execution.
Closure of every finding raised in the previous test cycle, because results obtained while earlier weaknesses remain open cannot be interpreted.
Open findings from a previous cycle influence how results are read, but they are not a precondition for starting the next run and closing them all is rarely feasible.
One trial execution of each intrusive test case against a publicly available test range, to demonstrate that the technique is harmless before it is used.
A public range behaves nothing like the tax portal, so such a run demonstrates little. It is not a step the security test process requires.
An announcement of the planned attacks to all portal users, so that unusual system behaviour during the window is not mistaken for a genuine incident.
Coordination is needed with operations and monitoring staff, not with the user population; announcing planned attacks broadly would itself create risk.
Because security testing uses intrusive and potentially damaging techniques, explicit approval from management for the planned activities, scope and time window is a mandatory precondition for starting execution.
In the security test process, which work product is derived directly from abstract (conceptual) security tests?
Concrete security test cases, carrying specific input data, preconditions and the expected result for each case.
Correct. Abstract tests state the idea of the test; making them concrete by adding data and expected results produces the test cases.
Security test procedures and scripts that put the tests into an executable sequence with the steps and tooling needed to run them.
Procedures and scripts come one step later, after the abstract tests have been turned into concrete test cases.
The threat model that identifies which assets an attacker would target and by which routes those assets can be reached.
The threat model is an input to the process. It informs the abstract tests rather than being derived from them.
The security risk analysis that ranks the identified risks by likelihood and impact so testing can be prioritised.
Risk analysis is also an input used to prioritise the test approach; it precedes rather than follows the abstract tests.
The progression is abstract or conceptual tests, then concrete test cases with specific data and expected results, then test procedures or scripts that put the cases into an executable sequence.
A government tax portal is setting up an environment for its security testing. Which TWO characteristics make such an environment effective?
It reproduces the production configuration in the aspects that govern security behaviour, in particular the access rights, role delegations and privilege boundaries.
Correct. If rights and delegation differ from production, an authorisation test result in the environment says nothing about production.
It allows intrusive and destructive techniques to be executed without putting live taxpayer data or live users at risk.
Correct. Security testing damages state and floods interfaces, so the environment must absorb that without production consequences.
It shares the identity store with production, so that real taxpayer accounts and their real credentials can be reused for realism.
Sharing the production identity store puts live credentials and personal data into the reach of the tests, which is the opposite of what is wanted.
It is restored from a clean backup after each individual test case, so that no test case can be affected by the one before it.
Restoring between suites is often sensible, but per-case restoration is disproportionate and is not a defining characteristic of effectiveness.
It holds only synthetic data at the lowest classification level, which removes the need to configure security controls inside the environment.
Synthetic data is good practice, but the controls themselves are the object under test, so leaving them unconfigured makes the environment useless.
An effective security test environment reproduces the production aspects that govern security behaviour — notably access rights, role delegation and privilege boundaries — and at the same time allows intrusive and destructive techniques to be used without endangering live data or live users.
Which statement characterises exploratory security testing?
Test design, execution and learning proceed together inside a time-boxed charter, with the tester using what each result reveals to choose the next attack.
Correct. Concurrent design and execution guided by observation, within an agreed charter, is what makes the approach exploratory.
The complete set of security test cases has to be specified, reviewed and approved before the tester may begin a session.
That describes scripted testing. Pre-specifying every case removes exactly the freedom exploratory testing depends on.
It takes the place of risk-based test design, because the relevant security risks are discovered by the tester during the session itself.
Exploratory sessions are usually chartered from the risk analysis and threat model; the two approaches complement each other rather than substitute.
It is used only once all scripted security tests have passed, as a final confirmation activity before the release decision.
Exploratory sessions can be run at any point, and are often most valuable early, when little is yet known about how the system behaves under attack.
In exploratory security testing, design, execution and learning proceed together within a time-boxed charter: the tester uses what each observation reveals about the system to choose the next attack, and records the session so findings remain reproducible.
A telecom operator's billing chain contains two components. The rating engine turns each call detail record into a charge; the discount service applies subscriber-specific promotions. Both have been fuzz-tested and code-reviewed at component level and carry no open findings. A documented security risk analysis, built on a threat model of the chain, records the following: the rating engine accepts the discount percentage returned by the discount service without bounding it, and the discount service echoes back any percentage present in the caller's request context. Neither component can produce a mispriced invoice on its own — the effect appears only when the two are wired together. Which test level and technique should you select to address this risk?
Component integration testing of the rating engine together with the discount service, driven by the documented risk analysis, injecting an out-of-range discount percentage at the interface between them and checking whether the resulting charge is bounded.
Correct. The defect is an interface trust assumption between two components, so integrating exactly those two and attacking their interface is the level and technique that can expose it.
Component testing of the discount service in isolation, fuzzing its percentage field, because that component is where the unbounded value originates and is therefore the root of the risk.
In isolation the discount service behaves as specified — it echoes a value. The harm appears only once the rating engine consumes it, so component testing cannot detect the risk.
System testing of the whole billing chain using a full end-to-end business scenario, on the grounds that only the complete chain produces the invoice the subscriber finally receives.
System testing could eventually reveal the symptom, but it is later, more expensive and far weaker at isolating a two-component interface defect that is already precisely described.
Acceptance testing with the billing operations department, validating the end-to-end invoicing business process against the documented security requirements for charging.
Acceptance testing validates business requirements with the stakeholder. It is the wrong level for a technical trust assumption on an internal interface.
The risk lives in the interface between two components and cannot be reproduced by either alone, which is exactly what component integration testing addresses. The syllabus notes that such testing should be driven by a documented risk analysis with realistic threat modelling — available here — and the technique is to inject the out-of-range value at the interface and observe whether the consumer bounds it.
A video streaming provider has to observe one security standard because a national regulator requires it, and has chosen to follow a second one voluntarily. What difference does the mandatory versus voluntary nature of the two standards make to security testing?
Non-conformance with the mandatory standard has consequences imposed from outside, so its normative clauses become obligatory expected results, while for the voluntary one the organisation itself chooses which recommendations to adopt and how deeply to verify them.
Correct. The distinction determines whether conformance is negotiable and therefore how firmly the standard's clauses bind the test oracle.
Only the mandatory standard can act as a source of test oracles, because a voluntary standard offers recommendations rather than defined expected results.
Voluntary standards and best practices are explicitly useful oracle sources; once adopted, their clauses supply expected results just as well.
Once both have been adopted they are applied in exactly the same way, since the clauses of a standard carry identical force whatever the reason for adopting it.
The clauses read the same, but the consequence of deviating differs sharply, and that consequence is what drives how much verification effort each one justifies.
The voluntary standard has to be followed in full including its informative clauses, whereas for the mandatory standard only the normative clauses are relevant.
The obligation to follow a standard in full does not arise from adopting it voluntarily; and the normative-versus-informative distinction applies to both standards alike.
For a mandatory standard, non-conformance has external consequences imposed by the regulator, so its normative clauses become obligatory expected results. For a voluntary one, the organisation itself decides which recommendations to adopt and how deeply to verify them.
An HR and recruitment SaaS vendor has finished a new candidate-assessment module. It sits in the test environment but has not been deployed to any tenant: there is no production URL, no configured identity provider and no real applicant data. Static analysis reports that user-supplied free text is concatenated into a database query in three places. The security test lead scores the finding with CVSS and arrives at 4.3, largely because the vector requires assumptions about an attack surface that does not yet exist. On that number the triage board ranks the finding below four medium findings in the live payroll module and defers it. Which action applies the syllabus guidance correctly, and why does the choice of scoring scheme change the priority?
Re-score the finding with CWSS: CVSS presumes a deployed configuration, so for an undeployed module its exploitability and environmental inputs must be guessed, whereas CWSS scores the weakness itself and carries the uncertainty about the eventual deployment explicitly.
Correct. This is the case CWSS exists for, and it changes the priority because the score then reflects the code defect instead of an attack surface that has yet to be built.
Retain the CVSS score of 4.3 and revisit the finding once the module has gone live, since a weakness that cannot currently be reached by an attacker carries no risk while the module stays undeployed.
This is precisely the shift-left failure the guidance warns against: the weakness is cheapest to remove now, and deferring it to deployment guarantees it ships.
Score the finding with CWSS and then adjust its CVSS value to the same number, so that every item on the triage board can still be compared on a single common scale.
The two schemes measure different things on different scales; forcing one to match the other destroys the meaning of both scores.
Discard the static analysis finding and re-test the module with a dynamic tool, because only a score fed by observed exploitation of a running system can be defended to the triage board.
Discarding a confirmed weakness because the dynamic evidence is missing loses real information, and the module has no deployment for a dynamic tool to attack in the first place.
CVSS assumes a vulnerability in a deployed configuration; its exploitability and environmental inputs have to be invented for a component that is not deployed, which pushes the score down for the wrong reason. CWSS scores the weakness itself and explicitly accommodates uncertainty about the future deployment, so the finding is prioritised on the code defect rather than on an attack surface that does not exist yet.
You are threat-modelling the operator console of an energy grid dispatch system using STRIDE. The design review produces two facts. First, the console identifies the substation gateway it talks to only by hostname, resolved through an internal DNS server that any host on the operations network is permitted to update. Second, the console's 'shift supervisor' role is carried by a claim inside a session cookie that the console writes itself and does not sign. Which TWO STRIDE categories capture the threats that these two facts introduce?
Spoofing: any host able to update the internal DNS record can present a rogue endpoint that the console accepts as the genuine substation gateway.
Correct. Identity of the remote endpoint rests on a name that an attacker controls, which is the definition of a spoofing threat.
Elevation of privilege: an ordinary operator can edit the unsigned role claim in the cookie and act with shift-supervisor authority that was never granted.
Correct. A client-modifiable authorisation claim lets a user obtain rights beyond those assigned, which is elevation of privilege.
Information disclosure: the hostname of the substation gateway becomes visible to every host on the operations network through the DNS records.
A hostname in internal DNS is not sensitive information, and the threat described is about who the console ends up talking to, not about what is revealed.
Denial of service: resolving the gateway by hostname introduces a dependency on DNS whose failure would leave the console unable to dispatch.
The availability dependency is real but it is a design consequence of using DNS at all, not a threat created by the two facts the review reported.
Repudiation: the console has no way to prove afterwards which operator issued a particular switching command to a substation.
Nothing in the two facts concerns the audit trail of issued commands; repudiation would need a separate finding about logging and command attribution.
An unauthenticated, writable name-resolution path lets an attacker present a rogue endpoint that the console accepts as the genuine gateway — spoofing. An unsigned role claim that the client can edit lets a normal operator assume supervisor authority — elevation of privilege.
The requirement specification for the new account area of a video streaming platform contains one sentence about password changes: 'Users shall be able to change their password.' It says nothing about whether the current password must be re-entered, what happens to sessions already open on other devices, or how a failed attempt is reported. The developers have implemented the function and you, as security test engineer, must decide what the expected result is before you can design any test. How should best practices be applied in this situation?
Derive the expected results from an established practice such as the OWASP secure coding guidance on authentication and session management — re-authentication before the change, invalidation of the other open sessions, no disclosure of which credential was wrong — record that document as the test oracle, and have the product owner confirm the derived expectations.
Correct. This is the intended use of best practices as an oracle source: fill the specification gap from a recognised reference and get the result agreed so it becomes a requirement.
Report the requirement as untestable and suspend all test design for the change-password function until the product owner has written a complete and unambiguous specification for it.
Reporting the gap is right, but stopping there leaves the function untested through the release. Best practices exist so testing can proceed against a defensible oracle meanwhile.
Test only what the sentence states — that a password can be changed — because taking expected results from an external document would verify behaviour the customer never asked for.
Security expectations are frequently implicit; confining the oracle to the literal sentence leaves session handling and re-authentication entirely unverified.
Take the behaviour the developers implemented as the expected result, on the grounds that they built the function following the platform's internal coding conventions.
Using the implementation as its own oracle means every implemented behaviour passes by construction, which is not a test at all.
Standards and best practices are legitimate sources of test oracles precisely where a requirement is silent. The engineer derives the expected results from an established practice such as the OWASP secure coding guidance for authentication and session management, records that document as the oracle, and has the derived expectations confirmed by the product owner so they become agreed requirements.
The regulator for the national electricity sector obliges grid operators to keep a tamper-evident record of every access to the dispatch control system for seven years, to make each record attributable to a named individual, and to be able to produce the records for a chosen period within 48 hours of a regulatory request. The operator's security policy has been amended to state these obligations. As security test engineer you must decide how the obligation changes your choice of techniques for the next test cycle. Which selection follows most directly from it?
Add tests that an access record is written for every access path including administrative and emergency accounts, that a record cannot be altered or deleted by the account that produced it, and that retrieval for a chosen period returns a complete set — including after the archive has rolled over.
Correct. Each of these targets one of the properties the regulator imposes: completeness with attribution, tamper evidence, and retrievability over the retention period.
Concentrate the cycle on penetration testing of the dispatch console's externally reachable interfaces, since what a sector regulator ultimately cares about is that the grid is not breached from outside.
Perimeter penetration testing is valuable but produces no evidence about record attribution, tamper evidence or retention, which is what this obligation actually constrains.
Add tests of the confidentiality of the access records, verifying that they are encrypted at rest in the archive and that no unauthorised person is able to read them.
A reasonable secondary objective, but the obligation is about integrity, attribution and availability of the records rather than their confidentiality.
Treat the obligation as a documentation matter and verify that the amended security policy cites the regulation correctly and that the retention period stated in it is indeed seven years.
Reviewing the policy text confirms that an intention was written down; it produces no evidence that the deployed system behaves as the regulation demands.
The regulation constrains three testable properties: completeness and attribution of the access record, its resistance to alteration by those who generate it, and the ability to retrieve a complete set of records for a period — including after the archive has rolled over. Techniques must be selected to produce evidence about exactly those properties.
A telecom group operates in six countries and its security testing capability is spread across them. Threat modelling and test design sit with a central team in one country. Execution is carried out by local security testers employed by each national operating company, who report to their own national security officer rather than to the central team. Findings are recorded in six different national tools and consolidated once a month. The group has asked you to plan the security testing of a new shared subscriber-provisioning platform that all six countries will use. Which planning measures follow most directly from this organisational structure?
Agree one shared test basis, one set of severity criteria and one finding format before execution begins, and schedule explicit coordination points — because the team that designs the tests has no authority over the testers who run them and results from six tools must be comparable before they can be consolidated.
Correct. Both the split of authority and the fragmented tooling are addressed: shared definitions make the results comparable, coordination points substitute for the missing line management.
Transfer the whole test effort for this platform to the central team and have it execute every test itself, since one shared platform ought to be exercised by one team whatever the security function's structure looks like.
This ignores the structure rather than adjusting to it: the central team lacks the national access, environment knowledge and local regulatory context that the local testers hold.
Let each country plan independently, choosing the techniques and the severity scale that suit its own operating company, and merge the six reports into a group view at the end of the cycle.
Six incompatible severity scales cannot be merged into a meaningful group view; the consolidation step that already exists is exactly what this would break.
Plan a single test cycle executed in the country with the strictest national regulation, on the assumption that a platform which satisfies the strictest regime satisfies the other five as well.
Regulations differ in kind, not only in strictness, and one national deployment does not exercise the configurations and integrations of the other five.
The structure separates the people who design the tests from the people who execute them and fragments the finding data across six tools. Planning must therefore fix a shared test basis, common severity criteria and one agreed finding format in advance, and build in explicit coordination points, because neither authority nor tooling is shared.
Over three weeks the following comes to light at a telecom operator. An internal document index was reachable without authentication and has been indexed by search engines; search-engine queries restricted to that host return 214 results, listing file names such as 'DC-North_gateway_runbook_v7' and 'billing_mediation_oncall_rota'. Separately, eleven employees named in that on-call rota have public professional-network profiles stating their exact job titles, the systems they administer and, for four of them, the vendor whose tooling they were recently certified on. Three of those four then received an individually written email that referred to that vendor's product by name and to their real line manager. The network intrusion detection system logged nothing at all during the three weeks. Analyse the scenario and select the TWO correct conclusions.
The attacker is in the information gathering stage, carried out entirely passively through search engines and social networks, and is now converting the collected profile data into spear phishing against named administrators.
Correct. Indexed-content queries and social-network profiling are the classic passive reconnaissance sources, and the tailored mails referencing real managers are the spear phishing that follows from them.
The intrusion detection system logged nothing because passive reconnaissance sends no traffic into the monitored network — the index and the profiles are queried at third parties — and the tailored mails arrive through the ordinary mail path rather than as recognisable attack traffic.
Correct. A network sensor can only report on traffic it sees; reconnaissance conducted against third-party services never crosses it, which is the structural blind spot here.
The attacker has already reached the exploitation stage, because obtaining runbook and rota file names means internal documents were exfiltrated from the data centre network.
Nothing was exploited and nothing was extracted from the network: the file names were published by the organisation itself through an unauthenticated, indexed index page.
The intrusion detection system missed the activity because its signature set was out of date, so keeping the signatures current would have brought the reconnaissance to light.
Signature currency is irrelevant when no packet from the attacker ever reaches the sensor; no signature can match traffic that does not exist.
Since no traffic from the attacker was observed, no attack is under way, and the exposed document index should be handled as a housekeeping task by the portal team.
The absence of observed traffic is a property of the detection method, not evidence of safety; the tailored mails show an attack is already in progress.
This is passive information gathering: search-engine reconnaissance of an exposed index plus social-network profiling, feeding a spear phishing attempt. It is invisible to a network intrusion detection system because the queries are answered by third parties, not by the operator's monitored network, and the phishing mail arrives over the ordinary mail path.
A national energy company's perimeter logged 41 minutes of traffic from a single source address last night; the chart below summarises it. The incident review adds the following facts. The source was one address in a consumer broadband range. Every request carried an identical User-Agent string naming a well-known free scanning tool and its version. The ports were walked in ascending numeric order with no randomisation and no timing evasion. When the scan reached an exposed management interface, the attacker ran the unmodified proof-of-concept exploit that had been published two days earlier for a vulnerability in that interface, failed because the interface was already patched, and made no further attempt. No log was cleared and no persistence artefact was found.
Analyse the evidence and select the TWO correct conclusions.
The evidence describes a low-skill, opportunistic attacker of the script-kiddie type using off-the-shelf tooling and a published exploit: the activity is noisy, self-identifying, uniform across the whole port range and abandoned at the first failure.
Correct. Every observed property points away from a patient, resourced adversary, who would randomise, throttle, rotate sources, hide the tool and persist after a failure.
Because such attackers rely on published exploits against whatever happens to be exposed, closure priorities shift towards patching internet-reachable components for which public exploits exist and towards reducing the exposed surface itself.
Correct. The attacker type determines what matters: exposure and patch latency for known issues, rather than defences designed against targeted, stealthy adversaries.
The uniform high-volume traffic across the entire port range is evidence of a resourced attacker deliberately generating noise in order to conceal a second, quieter intrusion running in parallel.
A noise-as-cover pattern would show a second, distinct traffic profile from another source. Here there is only one source, one tool and one rate throughout.
Since the exploit attempt failed against an already patched interface, the event needs no change in closure priorities and can be closed as a blocked attack.
The attempt failed by luck of timing: the exploit was two days old and the interface happened to be patched. That is exactly the margin the priorities need to protect.
The absence of cleared logs and of any persistence artefact indicates the attacker had already obtained the access that was wanted and therefore had no reason to come back.
Both absences are consistent with an attacker who lacks the skill or intent to hide and persist; the failed exploit shows no access was obtained at all.
Uniform coverage of the whole port range, a constant rate with no evasion, a self-identifying tool, an unmodified public exploit and abandonment at the first failure together describe a low-skill, opportunistic attacker — the script-kiddie profile. That profile shifts closure priorities towards promptly patching internet-reachable components for which public exploits exist and towards shrinking the exposed surface.
A government tax portal team is moving from a sequential lifecycle with one security test phase before release to two-week iterations, each of which can deliver a shippable increment. Which statement describes the effect on security testing?
The security test activities are decomposed so that they fit inside an iteration and become part of its definition of done, so each increment is assessed as it is built instead of in one phase before release.
Correct. This is the shift-left consequence of iterative development: smaller, repeated security activities integrated into every iteration.
Security testing is scheduled as a dedicated hardening iteration immediately before each release, leaving the ordinary feature iterations free of security activities.
This reproduces the sequential security phase under a new name: weaknesses accumulate through the feature iterations and are found at the point where fixing them is most expensive.
Responsibility for security testing passes to the operations team, because a two-week iteration is too short for security activities to be completed inside it.
Security activities can be sized to an iteration; handing them to operations means the increment is released before anyone has assessed it.
The overall number of security test activities falls, since each iteration delivers a smaller change than a sequential release did and smaller changes carry fewer weaknesses.
Each individual change is smaller, but the activities are executed far more often and regression scope grows, so the total effort rises rather than falls.
In an iterative lifecycle the security test activities have to be decomposed so that they fit inside the iteration and become part of its definition of done, shifting the assessment left into each increment rather than concentrating it in one phase before release.
While testing a video streaming platform, a tester finds that the endpoint returning a viewer's playback history accepts any numeric profile identifier and returns the history for that profile, requiring nothing beyond a valid session of any account. What does analysing this result to determine the nature of the vulnerability and its potential technical impact involve?
Establishing what kind of weakness it is — a missing ownership check on a directly referenced object — and what an attacker could technically achieve with it, such as enumerating identifiers to read arbitrary viewers' histories.
Correct. Nature means the class of weakness; potential technical impact means what the weakness makes technically possible for an attacker.
Establishing which developer introduced the missing check and in which release it first shipped, so that the fix can be assigned to the right team and traced.
Useful for handling the defect, but attribution and history say nothing about the class of weakness or about what an attacker could do with it.
Estimating the contractual penalties and the loss of subscriber trust that disclosure would cause, since impact is understood as the consequence for the organisation.
That is business impact, which is assessed later and by other roles. The analysis asked for here is the technical consequence of the weakness.
Reproducing the finding against the production service to confirm that the same behaviour occurs when live subscriber profiles are used as identifiers.
Reproducing an access-control flaw against live viewers' data would itself breach their confidentiality, and the class of weakness is already determinable from the observed behaviour.
Analysis of a result establishes what kind of weakness has been observed — here a missing ownership check on a directly referenced object — and what an attacker could technically achieve with it, such as enumerating identifiers to read the viewing history of arbitrary accounts.
Two days before the annual filing deadline, a government tax portal is carrying fourteen times its normal load. A critical finding has been confirmed: the session cookie issued after login is not scoped to the portal's own host, so browsers also send it to a legacy subdomain operated by a different team. A hotfix altering the cookie attributes and the login response has been deployed straight to production, bypassing the normal release path. The change touches the login handler, the session store and the logout handler. You must define what is to be tested now, in production, inside the peak window. Which scope is appropriate?
Confirmation testing that re-executes the test which exposed the finding, plus a risk-based security regression set over the functions the change touched — login, session validity, logout and session invalidation, and single sign-on to the legacy subdomain — selected so it can run without disturbing filing traffic.
Correct. Confirmation proves the fix; regression covers the areas the change could have broken; the risk-based selection is what makes execution in a peak production window feasible.
Confirmation testing alone: the change is a single cookie attribute and the finding can be shown to be fixed, so regression testing may wait for the first scheduled release after the deadline.
The change also touched the session store and the logout handler; a broken logout or session invalidation would go undetected through the busiest days of the year.
The complete security regression suite for the portal, executed against production at once, because a change deployed outside the normal release path invalidates all earlier security test evidence.
An unplanned deployment does not invalidate evidence for untouched areas, and a full suite against production at fourteen times normal load risks the availability of the filing service itself.
A regression run confined to the pre-production environment, on the grounds that it carries the same code and therefore yields evidence equivalent to a production run.
The hotfix went to production directly, so only production is known to hold that exact configuration; cookie scoping in particular depends on the live host and domain names.
Both activities are needed. Confirmation testing re-executes the test that revealed the finding to prove the fix works. Security regression testing then covers the functions the change touched — login, session validity, logout and session invalidation, and the single sign-on path to the legacy subdomain — with the selection kept risk-based and non-disruptive because it runs in production at peak.
A telecom operator's subscriber self-service platform has been built for years in a sequential lifecycle: a six-week security test phase preceded each of the two annual releases and closed with a manual penetration test and a signed security release report. The platform is now moving to DevOps with continuous deployment — up to thirty production deployments a day, each a small change, with no release gate and no fixed release date. You have been asked to analyse how the security testing activities are affected. Select the TWO correct conclusions.
Activities expressible as repeatable, tool-driven checks with a machine-decidable verdict must move into the pipeline and run on every change — static analysis of changed code, composition analysis of dependencies, automated security regression and configuration checks — since there is no release date for a six-week phase to occupy.
Correct. The absence of a release gate forces the deterministic, automatable checks to become per-change pipeline stages.
Activities that rest on human judgement and creative attack construction do not become pipeline steps: threat modelling of a new design, exploratory security testing and manual penetration testing are scheduled alongside the pipeline, triggered by design changes and by risk, and their results feed back into the automated checks.
Correct. These activities produce insight rather than a pass/fail verdict a pipeline can act on, so they are re-timed rather than automated, and they seed new automated checks.
Since every deployment carries a small change, the accumulated risk is lower, so the manual penetration test can be discontinued once the automated pipeline checks are in place.
Small changes accumulate into large architectural drift, and automated checks find only the weakness classes they encode. Discontinuing the manual test removes the only activity that constructs novel attacks.
The six-week security test phase should be kept unchanged and executed once a quarter against whatever is in production at the time, since continuous deployment does not alter what has to be tested.
By the time a quarterly phase reports, production has moved on by roughly 2,700 deployments, so its findings describe a system that no longer exists.
Security regression testing becomes the job of the rollback mechanism: a change that introduces a weakness is reverted within minutes, so re-running earlier security tests adds little value.
Rollback assumes the weakness was noticed, which is what the regression tests are for. A silent authorisation regression triggers no alert and no rollback.
Activities that can be expressed as repeatable tool-driven checks with a machine-decidable verdict have to move into the pipeline and run on every change, because a six-week phase has no slot left when there is no release date. Activities resting on human judgement and creative attack construction cannot become pipeline steps; they are scheduled alongside the pipeline, triggered by design change and by risk, and their results feed back into the automated checks.
An airline's contract with a booking channel partner states the security acceptance criterion as: 'no finding rated high or above may remain open at handover, and the authorisation model must be verified for all twelve partner roles.' How does an acceptance criterion of this kind influence the security test approach?
It shapes the approach: techniques have to be chosen that produce evidence for all twelve roles, the severity scale used in triage must match the agreed rating, and the exit criteria of the effort follow from the criterion.
Correct. Acceptance criteria are an input to test planning, determining coverage, technique selection and how the effort is judged complete.
It bears only on the handover decision at the end of the effort, leaving the choice of coverage and techniques entirely to the judgement of the security test team.
Treating the criterion as a final gate means discovering at handover that the evidence needed for twelve roles was never produced.
It takes the place of the security risk analysis, because the criterion already states which risks the partner considers relevant to the handover.
The criterion states a required result, not the risks. Risk analysis is still what identifies where the weaknesses are likely to be and what to attack.
It confines the team to black-box techniques, since only results observable from outside the system can be presented as evidence to an external partner.
Evidence from reviews and static analysis is equally presentable; nothing in the criterion restricts the techniques to externally observable behaviour.
Acceptance criteria state what must be covered and with what result, so they shape the choice of techniques, the coverage to be achieved, the severity scale used in triage and the exit criteria of the test effort.
Why are security test results fed as an input into an organisation's information security management system?
They convert assumed risk into measured risk: the ISMS uses them as evidence to update its risk assessment, judge whether the controls are effective in practice, and decide on treatment.
Correct. Feeding results into the ISMS is what allows security risk to be managed actively rather than on the basis of assumptions.
They are archived there so that the security test team can clear the evidence out of its own tools at the end of each test cycle.
The ISMS is a management system, not an evidence archive, and the point of the input is that decisions are taken from it.
A management system certificate can only be issued once a penetration test report has been attached to the management system documentation.
Certification depends on the management system meeting the standard's requirements; no single test report is the trigger for issuing it.
The management system then selects which security test cases the team executes in the following cycle, in place of the team's own test planning.
The ISMS sets objectives and priorities from risk, but test design and case selection remain with the security test team.
The ISMS manages security risk actively, and test results are the evidence that turns assumed risk into measured risk: they update the risk assessment, show whether controls are effective in practice, and drive treatment decisions.
An airline's information security management system needs metrics from security testing. Which property must such a metric have if the management system is to use it?
It must be defined so that measuring the same situation twice yields the same value, and so that a change in the value can be attributed to a change in the security posture rather than to the way it was collected.
Correct. Repeatability and interpretability are what make a metric a basis for management decisions over time.
It must be reducible to a single overall percentage, so that different systems in the estate can be ranked against one another on one figure.
Compressing security posture into one number hides which risks are covered, and comparability between different systems is not what makes a metric usable.
It must be collected by hand by the security test team, because a value produced automatically by a tool cannot be presented as auditable evidence.
Automated collection is usually more repeatable and more auditable than manual collection, and the collection method is not the criterion.
It must be derived from the number of security test cases executed, since effort is the only quantity that can be measured consistently across different systems.
Executed test cases measure activity, not security posture; a rising count can accompany falling risk coverage.
A metric is usable inside an ISMS only if it is defined precisely enough that measuring the same situation twice gives the same value, and if a change in the value can be attributed to a change in the security posture rather than to how it was collected.
An airline's information security management system reports that security testing covers 100% of its defined test objects: the booking web application, the check-in web application and two public APIs. The figure has stood at 100% for four consecutive quarters and the number of findings per quarter has dropped to two. The steering group is not convinced that security risk is being managed actively and asks you which new test objects would raise the maturity of the management system. Which proposal is the most appropriate?
Add the parts of the estate that have never been in scope — the identity provider and its federation with partner airlines, the internal crew and ground-staff back-office applications, the build and deployment infrastructure, the network zone configuration, and the workforce's response to social engineering — so coverage is measured against the real attack surface.
Correct. New test objects extend the scope over which coverage is claimed, which is the syllabus route to greater management system maturity.
Increase the number of test cases run against the four existing objects each quarter until the finding count rises again, since a rising finding count demonstrates that the testing has become more thorough.
More cases against the same four objects deepen an already saturated area and leave every untested attack path exactly as it was; the finding count is also not the objective.
Present the 100% figure to the steering group together with the four-quarter trend, since coverage of the defined test objects is precisely the metric the management system asked for and it is being met.
This is the situation the steering group is already dissatisfied with: the metric is met because the scope it is measured against is too narrow to be informative.
Replace the coverage metric with a count of open high-severity findings, so the management system measures the outcome of testing instead of the effort put into it.
Changing the metric changes the reporting, not the maturity; with the same four objects in scope the new number would be just as uninformative.
Maturity grows when the scope of what is tested grows to match the real attack surface. Complete coverage of a narrow set of test objects says nothing about the identity provider, the internal back-office applications, the build and deployment infrastructure, the network zoning or the workforce — all of which are attack paths into the same assets.
An interim security test report on an HR and recruitment SaaS platform is going to the customer's executive steering group. Which statement reflects the guidance on what that report should contain?
The summary conveys the impact of the identified risks in terms the steering group can act on, while the technical detail of individual vulnerabilities follows separately and reaches a controlled audience.
Correct. Reporting is tailored to the stakeholder, and the confidentiality of exploitable detail governs who receives it and when.
The summary carries the full reproduction steps for every finding, so that members of the steering group are able to verify each result for themselves.
Reproduction steps are working attack instructions and are of no use to this audience; widening their circulation increases the exposure of the live platform.
The report gives only the count of findings per severity level, because technical content of any kind is inappropriate in a report addressed to a steering group.
A bare count of findings gives the group nothing to decide on; what they need is the risk impact expressed in business terms.
The report is issued once all findings have been remediated, so that it describes a platform in which no weakness is still open.
An interim report exists precisely to inform decisions while findings are still open; withholding it removes the basis for prioritising the remediation.
The summary conveys the impact of the identified risks in terms the stakeholder can act on. The technical detail of individual vulnerabilities follows separately, to a controlled audience, because those weaknesses often exist in production as well.
The table below shows the raw output of a dynamic application security testing run against an HR and recruitment SaaS portal, together with what a tester observed when each finding was re-tested by hand outside the scanner's proxy. Six findings were raised: reflected cross-site scripting on the candidate search parameter, SQL injection on the vacancy filter, a missing HSTS header, a directory listing under /assets/tmp/, an insecure direct object reference on the applications API, and an outdated jQuery version in a bundled script.
You must evaluate these results and decide which of them are confirmed vulnerabilities. Which assessment is correct?
F-01 and F-05 are confirmed vulnerabilities with an observed effect, F-03 is a genuine configuration weakness, and F-02, F-04 and F-06 are false positives — an identical error page for every input, a 403 outside the tool's proxy and a bare version string are inference rather than observed effect.
Correct. Each row is judged on whether a manual re-test produced a real effect, which is what separates a confirmed vulnerability from a tool inference.
All six are confirmed vulnerabilities: the tool raised each of them and the manual re-test produced an observation for every row, so all six must be closed before the release.
An observation is not the same as a confirming observation; three of the rows record evidence that contradicts the tool's inference rather than supporting it.
F-01, F-02 and F-05 are confirmed and the rest are not, because those three are the rows the tool rated with High confidence and the tool's confidence rating is what determines acceptance.
Tool confidence is a heuristic about the detection, not evidence about the system; F-02 carries High confidence yet its manual re-test refutes injection outright.
Only F-01 is confirmed, since it is the one row in which the tester saw code execute; the remaining five are statements about configuration or about the scanner's own proxy behaviour.
F-05 was reproduced as one recruiter retrieving another recruiter's applicant file, which is a confirmed authorisation failure even though no code executed.
Evaluation means comparing what the tool inferred with what was actually observed. F-01 and F-05 were reproduced with a real effect, so they are confirmed. F-03 is a genuine configuration weakness: the header really is absent and plain HTTP really answers. F-02, F-04 and F-06 are false positives — an identical error page for every input contradicts injection, a 403 outside the proxy shows the listing was an artefact of the tool's own session, and a version string with no reachable vulnerable sink is not an exploitable weakness.
On a Friday afternoon you confirm that the HR and recruitment SaaS platform allows any authenticated recruiter to retrieve the applicant file belonging to any other recruiter's vacancies — CV documents and stated salary expectations for roughly 90,000 candidates. The same code is live in production. The customer's normal process is to record findings in the shared project tracker, which all 140 project members including external contractors can read, and to discuss them at the Wednesday quality meeting. How should this finding be communicated?
Escalate immediately, outside the normal channel, to the named security contact and the system owner over a protected route; restrict the technical detail to those who need it to decide or to fix; and record it in a defect tracker with restricted access.
Correct. The criticality of the finding and its presence in production drive both the urgency and the narrow, controlled audience for the detail.
Record it in the shared project tracker with the full reproduction steps straight away, so that every project member is aware of the risk and nobody can later claim the finding was concealed.
This publishes working attack instructions against live candidate data to 140 people, contractors included, while the weakness is still open in production.
Hold the finding until the Wednesday quality meeting and present it there with the rest of the cycle's results, so the customer receives one coherent set of findings.
A five-day delay on a live exposure of 90,000 candidate files is not defensible; critical findings are escalated when they are confirmed.
Report it verbally to the security contact and keep it out of every tracker, so that no written record of the weakness exists while production remains exposed.
Confidentiality is achieved by restricting access, not by leaving no record; without a tracked entry the fix cannot be assigned, followed up or confirmed.
Critical security findings that also exist in production are handled outside the ordinary channel: they are escalated immediately to the security contact and the system owner over a protected route, the detail is restricted to those who need it to decide or to fix, and the record is kept in a tracker with restricted access.
A security test team is categorising its toolset along the static/dynamic and white-box/black-box dimensions. Which pairing of tool type and category is correct?
Software composition analysis is static and white-box: it reads the product's declared dependency manifests and packaged binaries without executing it.
Correct. Nothing is executed and internal artefacts of the build are required, which places the tool in the static, white-box category.
Fuzzing is static and white-box, because the malformed inputs are generated from the source code before any part of the system is run.
Input generation may use the source, but the inputs are then fed to a running target and its reaction observed, which makes fuzzing dynamic.
Vulnerability scanning is static and black-box, because it compares the version numbers it finds against a database rather than executing the system.
The scanner has to interrogate a live host or service to discover those versions and behaviours, so it operates dynamically.
Penetration testing tooling is static and white-box, since the tester needs the design documentation of the target in order to plan the attacks.
Penetration testing executes attacks against the running target, and it is often conducted with limited internal knowledge, so neither part of the pairing holds.
Software composition analysis reads declared dependency manifests and packaged binaries without executing the product, and it needs internal artefacts to do so — a static, white-box tool. Fuzzing, vulnerability scanning and penetration testing all require the target to be running.
A team is selecting a security testing tool for its energy-sector customer. Which selection consideration is specific to security testing tools rather than applying to test tools in general?
How frequently the supplier refreshes the tool's knowledge of vulnerabilities and attack patterns, because a tool with stale knowledge reports against an attack landscape that has moved on.
Correct. Security tools are only as good as the currency of the threat knowledge they carry, which is not a concern shared by test tools in general.
Whether the tool can export its results in a machine-readable format that the team's reporting chain is able to consume without rework.
A sensible requirement, but integration and result exchange apply to any test tool the team might select.
Whether the tool runs on the operating systems and platform versions already in use across the test team's workstations and build agents.
Platform compatibility is a general tool selection concern and says nothing about the tool's security capability.
Whether the licensing model permits as many concurrent users as the team has members, so that execution is not serialised across the team.
Licensing constrains any tool acquisition equally; it is not a consideration arising from the security nature of the tool.
Security tools depend on knowledge of current vulnerabilities and attack patterns, which ages quickly. How frequently the supplier refreshes that knowledge is therefore a selection criterion peculiar to security testing tools.
A video streaming provider has bought a recommendation service from a supplier. What the provider receives is a deployable container image, the interface documentation and a runtime agent that the supplier supports — but no source code and no build. The service is already deployed in the provider's integration environment and is serving real request traffic there. The security risk analysis names two risks: injection through the free-text search parameter, and authorisation gaps in the internal endpoints that the documentation does not describe. Which tool selection fits this situation, and on what grounds?
Dynamic analysis against the deployed service, complemented by interactive analysis through the supplier's runtime agent: no source is available for a static tool to read, the service is deployed and serving traffic, and the agent adds the code-level location of findings observed from outside.
Correct. The absence of source rules static analysis out, while the deployed, traffic-serving state is precisely the phase and access that dynamic and interactive tools require.
Static analysis of bytecode decompiled from the container image, because a static tool gives the precise code location of a weakness and injection is a code-level defect.
Decompiled third-party bytecode yields noisy, hard-to-triage results, and it would still leave the undocumented internal endpoints — discoverable only at runtime — unexamined.
Static analysis first and dynamic analysis only if the static run reports nothing, following the usual sequence of applying static techniques before dynamic ones in the lifecycle.
The shift-left ordering assumes the code is yours and available early. Here neither condition holds, so applying the sequence mechanically wastes the cycle.
Software composition analysis of the container image on its own, because the risks in a purchased service originate in the third-party components the supplier bundled into the image.
Composition analysis would find vulnerable bundled libraries, but neither named risk is a dependency issue — both are in the service's own request handling and authorisation logic.
Tool selection follows from the phase and the access available. There is no source code, so a static analyser has nothing meaningful to read; the service is deployed and serving traffic, which is exactly what dynamic tools need. Instrumenting it with the supplier's runtime agent adds interactive analysis, which reports the code-level location of a weakness that a purely external tool can only observe from outside.