ISTQB Specialist (CT-STE v1.0.1) Mock Exam #3 — 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 university keeps three data sets in the same student platform: the public course catalogue, the internal exam question bank, and the records of the student health service. Before test planning starts, the security team assigns each data set a protection level. What is the main purpose of assigning security levels to assets in this way?
It states how much protection each data set needs, so the depth and rigour of security testing can be matched to the asset
Correct. Security levels classify assets by the protection they require, and that classification drives how strictly each asset is tested.
It records which university department owns each data set, so that defect reports are routed to the correct maintainer
Ownership records help with defect routing, but that is a configuration-management concern; a security level expresses required protection, not responsibility for fixes.
It fixes the retention period of each data set, so that obsolete student records are purged on a defined schedule
Retention periods are a data-management rule that may follow from regulation; they are not what an asset security level expresses.
It ranks the data sets by how likely they are to contain functional defects, so that functional test effort can be distributed
Defect likelihood is an input to functional test prioritisation. Asset security levels are about the value and sensitivity of the asset, not about expected defect density.
Asset security levels express how much protection an asset needs. That judgement is what lets the test team decide how deep and how rigorous the security testing of each asset has to be, instead of treating all data identically.
A ride-hailing platform stores two things behind the same web front end: a public fare table and scanned driver licence documents. Both are reachable through the same set of REST endpoints. How should the difference in sensitivity between these two data sets influence the security testing?
The endpoints handling the licence scans are tested more thoroughly, with stricter checks on access control and on protection in storage and transit
Correct. Higher information sensitivity justifies deeper coverage and stricter pass criteria for the paths that expose that information.
Both data sets are tested with the same set of test cases, because they share one technical interface and one deployment
A shared interface does not equalise the consequences of a breach. Sensitivity, not deployment topology, sets the required test rigour.
The fare table is tested first and more deeply, because it is publicly reachable and therefore exposed to more traffic
Exposure volume alone does not justify the deeper effort. Public data has little confidentiality value, so a leak of the fare table has minor consequences.
The licence scans are excluded from the test scope and covered by a separate data-protection review instead of by testing
A separate review may be useful in addition, but moving the most sensitive asset out of the test scope leaves its protection unverified.
The sensitivity of the information determines how strict the security testing has to be. The more sensitive asset justifies more test coverage and more demanding checks, even when both assets sit behind the same technical interface.
A municipal library is undergoing a security audit of its lending and city-account services. Which two statements correctly describe the role of security testing within such a security audit? (Choose two.)
Security testing provides the audit with evidence on how the implemented controls behave in practice, not only on how they are documented
Correct. Testing turns claimed control behaviour into observed behaviour, which is exactly the evidence an audit needs.
Audit observations can identify areas of the library services where additional security testing is needed
Correct. The audit and the testing feed each other: audit findings become input for further test design.
A security audit consists of the security test activities, so a completed test report is a completed audit
An audit is broader than testing: it also reviews policies, processes, roles and documentation. A test report is one input to it.
Security testing is performed only after the audit has been closed, using the audit report as its only source of test conditions
Testing is not restricted to a post-audit phase, and it draws test conditions from risk analyses, threat models and requirements as well.
Security testing during an audit is limited to reviewing the library's security policy documents against the applicable standard
That describes a document review. Security testing also exercises the running system dynamically.
Security testing supplies the audit with factual evidence about how the implemented controls actually behave, and audit findings in turn identify areas that need to be tested. The audit itself is broader than testing: it also examines policies, processes and documentation.
Which statement best describes the concept of zero trust as a security paradigm?
No request is trusted because of its origin; every request is authenticated and authorised on its own, whether it comes from inside or outside the network
Correct. Zero trust removes implicit trust derived from network position and evaluates each request individually.
Traffic inside the internal network is trusted, while traffic crossing the perimeter is inspected and filtered
This is the perimeter-based model that zero trust was formulated to replace: it grants implicit trust based on location.
Users are granted a single strong authentication at login, after which their session is trusted for all subsequent operations
A one-off authentication that blanket-trusts the rest of the session is the opposite of continuous per-request verification.
All components are treated as untrustworthy, so data is encrypted at rest and no access control decisions are needed
Encryption is one control among many; zero trust relies heavily on access control decisions rather than removing them.
Zero trust removes the assumption that a request is trustworthy because of where it comes from. Every request is authenticated and authorised on its own merits, regardless of network location.
A donation-collection platform is assembled largely from reused open-source software (OSS) components. What is a consequence of this reuse that the security test approach has to take into account?
Publicly known weaknesses of the reused components, and of the components they depend on in turn, are part of the platform's attack surface and must be covered by testing
Correct. Reuse imports both the component and its known weaknesses, including those of its own dependencies.
Because the source code of the components is public and has been reviewed by many people, the reused parts can be left out of the security test scope
Public review reduces but does not remove risk, and the platform's own configuration and integration of the component are untested by anyone else.
Only the versions of the components matter, so recording version numbers in the release notes is a sufficient security measure
Version inventory is useful input, but recording a version is not a test of whether the version's weaknesses are exploitable in this platform.
The reused components shift responsibility for their security defects to their maintainers, so the platform team tests only the donation workflow it wrote itself
The operator remains accountable for the deployed system. OSS maintainers carry no contractual obligation to the platform.
Publicly known weaknesses of a widely reused OSS component are known to attackers as well, and the component's own transitive dependencies extend the attack surface. Both mean the reused parts need explicit security test attention, not only the code written in-house.
An agritech company operates 1 800 soil and irrigation sensors installed in open fields across four regions. Each sensor is a small gateway-connected device in an unlocked plastic housing on a post; anyone walking through the field can physically reach it, open it and attach a cable. The sensors report over a private APN that the original design document calls "the trusted farm network", and the platform therefore accepts any measurement, firmware heartbeat or configuration read-back that arrives from that network without further checks: there is no per-device credential, and the gateway forwards whatever it receives. The security test lead is asked to redesign the tests for this data path applying zero trust. Which test design follows from applying the zero trust paradigm here?
Design tests that submit measurements and configuration reads from a device identity the platform does not know, and from a known device acting outside its assigned scope, both injected from inside the private APN, and require the platform to reject them
Correct. Applying zero trust means the tests must prove that each request is authenticated and authorised on its own merits, so the test position must be inside the supposedly trusted network.
Design tests that confirm the private APN cannot be reached from the public internet, and that the gateway rejects connections from any address outside the APN range
This keeps the perimeter model and only hardens it. It leaves untested the case zero trust is concerned with, namely a request that already originates inside the APN.
Design tests that check the physical housing of a sample of sensors for tamper marks and verify that field technicians follow the inspection procedure
Physical inspection may be a worthwhile control, but it is not the application of zero trust to the data path and it verifies nothing about how the platform handles requests.
Design tests that measure whether the platform still ingests the full sensor volume when the number of connected devices doubles, so that trust decisions do not slow ingestion down
This is a capacity concern. It says nothing about whether the platform verifies the identity and permissions of the sender.
Design tests that verify the measurement payloads are encrypted end to end, so that intercepted field traffic cannot be read
Confidentiality of the payload is useful, but an attacker with a rogue device on the network sends validly encrypted traffic; only per-device authentication and authorisation address that.
Zero trust removes the implicit trust that the private APN currently confers. Because the device is physically accessible, an attacker can place a rogue or reflashed device on the "trusted" network. So the tests must verify that the platform authenticates and authorises each device and each message on its own, and must be designed to attempt exactly that impersonation from a position inside the private network.
A test team working on a real-estate listing platform is given the API specification, the database schema and the deployment diagram, but not the application source code. They exercise the running system through its interfaces while using those documents to choose their inputs. How is this security test approach classified?
Grey-box testing, because internal structural information guides tests that are executed through the external interfaces
Correct. Partial internal knowledge combined with interface-level execution is the grey-box case.
White-box testing, because the database schema and deployment diagram describe the internal structure of the system
White-box security testing works on the implementation itself, typically the source code. Schema and diagrams are partial information, which makes the approach grey-box.
Black-box testing, because the source code is unavailable and the tests are run through the published interfaces
Black-box testing assumes no internal information is used. Here the schema and deployment diagram are deliberately used to select inputs.
Static testing, because the API specification, schema and deployment diagram are examined as part of the work
Reading documents to design tests does not make the approach static; the tests themselves are executed against the running system, which is dynamic.
Grey-box testing combines internal information about the structure of the object under test with testing performed through its external interfaces. Full source-code access would be white-box; no internal information at all would be black-box.
The ISTQB Security Test Engineer syllabus notes that the classification of security test types into static and dynamic has "fuzzy overlaps" in practice. What does this observation mean for a test engineer?
A single technique or tool can carry properties of more than one category, so the categories serve as a planning aid rather than as mutually exclusive labels
Correct. The overlap is real, and the classification is still valuable for reasoning about what a test approach does and does not cover.
The classification has no practical value, so test approaches should be selected purely from the list of available tools
Overlapping boundaries do not make the classification worthless; it still structures thinking about coverage and about what evidence each approach yields.
Every security test must be assigned to exactly one category before execution, and ambiguous cases must be split into separate tests
Forcing an artificial split is not what the observation implies; the point is that a technique may legitimately span categories.
Static techniques and dynamic techniques find the same weaknesses, so applying one of the two is enough for a given test object
The two examine different things, one the artefact and one the running behaviour, and they find different weaknesses. Overlap in classification does not mean equivalence in results.
The categories are useful for reasoning about coverage, but a real technique or tool can sit across a boundary, for example by instrumenting code and observing it while it runs. The engineer should therefore treat the categories as a planning aid rather than as strict, mutually exclusive buckets.
A gaming marketplace separates identification, authentication and authorization in its identity and access management control. Which two of the following are tests of authorization rather than of authentication? (Choose two.)
A logged-in player requests the moderation endpoint that is reserved for marketplace staff, and the request must be refused
Correct. The identity is already established; what is checked is whether that identity is permitted to perform the operation.
A logged-in player retrieves the wallet history of a different player by changing the account identifier in the request
Correct. This tests whether permissions correctly restrict which objects an authenticated identity may reach.
A login attempt is made with a valid user name and a wrong password, and access must be refused
This checks whether the claimed identity can be proven, which is authentication.
A login attempt with a valid password is made while the second factor is deliberately omitted
The second factor is an additional proof of identity, so this remains an authentication test.
An account is locked after a defined number of consecutive failed sign-in attempts
This exercises a protective measure attached to the authentication process, not the evaluation of permissions.
Authentication establishes that a claimed identity is genuine. Authorization establishes what an already authenticated identity is permitted to do. Tests that vary the permitted operation or the accessed object, keeping the identity fixed, target authorization.
A connected-car telematics service encrypts the vehicle position history it stores. Which check belongs to testing the encryption and data protection control itself?
Verifying that the algorithm and key length in use are adequate and that keys are generated with sufficient randomness
Correct. A weak algorithm, an undersized key or a predictable key makes the control ineffective even when encryption is switched on.
Verifying that encrypted position records can be written and read back at the throughput the service requires
This measures performance of the storage path. It shows the feature works, not that the protection is strong.
Verifying that the vehicle owner can export the position history in a documented file format
Export functionality is a functional requirement, possibly one derived from a regulation, but it is not a test of the encryption control.
Verifying that the field storing the encrypted value is wide enough to hold the ciphertext produced for the longest journey
This is a data-definition check that prevents truncation defects. It does not evaluate the strength of the protection.
Testing an encryption control means examining the properties that make it effective: whether the algorithm and key length are adequate, whether keys are generated with sufficient randomness and handled properly, and whether data really is protected where it is claimed to be.
A municipal library runs malware scanning on every file that patrons upload to the community-notice service. What limitation of malware scanning must the test approach take into account?
The scanner detects the threats its detection data covers, so an upload that passes the scan is not thereby shown to be harmless
Correct. Detection depends on what the scanner has been given to recognise, which is why a clean result is weak evidence.
The scanner inspects only file names and extensions, so any content check has to be added by the application itself
Malware scanners inspect file content. The real limitation lies in the coverage of their detection data, not in a refusal to look inside files.
The scanner reports findings only after the file has been stored, so uploads cannot be rejected before they reach the file store
Scanning can be placed in the upload path before storage. This describes one possible integration choice, not a limitation of the technique.
The scanner covers executable formats only, so documents and archives must be tested with a different protective technology
Scanners handle documents and archives too. The constraint is which threats their detection data recognises, regardless of format.
A malware scanner recognises what its detection data allows it to recognise. Threats that its signatures and rules do not cover pass through, so tests must not treat a clean scan result as evidence that an upload is harmless.
Which description matches destructive testing as a security test technique?
The test object is deliberately driven beyond its specified limits so that its failure behaviour, and any insecure state left behind, can be observed
Correct. The value of destructive testing lies in what the system does when it breaks, which normal testing never reaches.
Test data is deleted from the environment after each execution so that later tests start from an identical baseline
That describes test-data management and environment resetting, not a technique aimed at failure behaviour.
Findings are exploited to the point of taking full control of the object, in order to prove the finding is genuine
Exploiting a finding to demonstrate it is characteristic of penetration testing; destructive testing is about behaviour beyond specified limits.
The security controls are switched off one at a time to measure the contribution each of them makes to the overall protection
Disabling controls to measure their contribution is a form of control-effectiveness analysis, and it stays inside specified operating conditions.
Destructive testing deliberately drives the test object beyond its specified operating conditions, in order to observe how it fails and whether the failure leaves it in an insecure state. That is why it needs an environment where damage is acceptable.
A university runs a student records system used by 340 staff across 11 faculties. The access policy defines 14 roles and states exactly which record types each role may read and change. Over the past three years, however, permissions have been granted individually and manually: exam officers who covered for a colleague, doctoral supervisors who needed one extra faculty, contractors added for a migration project. Nobody removed those grants, and the system now holds 2 900 individual permission entries with no record of why most of them exist. The security test lead is asked to design reconciliation testing for these permissions. Which test design does that require?
Extract the effective permissions of every account, derive the permissions the 14 documented roles would grant the same accounts, and report each account whose effective permissions differ from the derived set
Correct. Reconciliation compares the actual state against the policy-derived expected state across the whole population, which is what exposes the accumulated undocumented grants.
Design negative tests in which an account from each of the 14 roles attempts an operation that its role forbids, and confirm each attempt is refused
This tests that the authorization mechanism enforces a role correctly, which is valuable but says nothing about which permissions the 2 900 entries actually assign.
Ask each of the 11 faculty administrators to confirm in writing that the permissions of their staff are still appropriate, and record the confirmations as the test result
A written attestation is a recertification-style administrative step, not a test; it produces opinions about the policy rather than measured facts about the system state.
Run a vulnerability scan against the records system and its database, then map every finding that concerns access control to the affected accounts
A scan looks for known weaknesses in the software and its configuration. It cannot tell whether a granted permission contradicts the access policy.
Review the audit log of the last three years and design a test for each permission change that was made without a recorded approval reference
Log review may explain how the state arose, but it measures the change history rather than the current gap between effective permissions and policy, and grants predating the log are missed.
Reconciliation testing for identities and permissions compares the permissions actually in effect in the system with the permissions the policy defines, and reports every difference. The essential element is the comparison against the policy as the reference, over the whole population of accounts, so that grants nobody can justify are surfaced.
A donation platform is starting its security test process. Which combination of inputs does test analysis in the security test process primarily draw on?
The available threat models, the security risk analysis and the security requirements
Correct. These three define the threats to address, their relative importance and the properties the system is required to have.
The defect reports of the previous release and the list of tools the organisation has licensed
Past defects and available tools inform execution and estimation, but they do not establish what has to be protected against what.
The production monitoring dashboards and the platform's uptime statistics of the last quarter
Operational data is useful feedback, particularly during maintenance, but it is not the primary basis for security test analysis.
The user documentation and the published release notes of the reused third-party components
These can supply detail while designing individual tests, yet they neither express the risks nor state the security requirements.
Security test analysis works from the available threat models, the security risk analysis and the security requirements. Together these define what has to be protected, against what, and to what degree.
In a security test process, on what basis are the security tests prioritised?
On the test approach together with the identified security risks and the threat models
Correct. Risk and threat information, interpreted through the chosen approach, determines which tests matter most.
On the order in which the components were developed, so that the oldest code is examined first
Development sequence is unrelated to the significance of a threat; old code is not automatically the riskiest.
On the number of interfaces each component exposes, so that the widest interface is tested first
Interface count is a crude proxy for attack surface, but it ignores the value of the assets behind the interface and the credibility of the threat.
On the execution duration of the tests, so that the fastest tests deliver results earliest
Running the quick tests first can help feedback speed, yet it is a scheduling tactic rather than the basis of prioritisation.
Prioritisation follows the agreed test approach together with the identified security risks and the threat models, so that the tests addressing the most significant threats are executed first.
A ride-hailing company is setting up an environment for security testing. Which two characteristics make such an environment effective for security testing? (Choose two.)
Its configuration, including the protective technologies in place, is close enough to production that a finding there is credible for production
Correct. Security findings depend heavily on configuration, so a divergent environment produces results that do not transfer.
It is isolated and controlled, so aggressive tests can be run without affecting production services or exposing real customer data
Correct. Security testing includes intrusive activity, which needs an environment where the consequences are contained.
It is shared with the functional test team, so that security tests always run against the same build as the functional tests
Sharing may be convenient, but intrusive security tests disrupt other testing and a shared environment weakens the control the security tests need.
It is rebuilt from scratch before every individual test case, so no residue of an earlier test remains
A clean starting state is often desirable, but rebuilding per test case is not a defining characteristic and would prevent tests that depend on an accumulated state.
It runs a copy of the live customer database, so that the test data is realistic in volume and in content
Live personal data in a test environment creates the exposure the testing is meant to prevent; realism is achieved with anonymised or generated data.
An effective security test environment resembles the production configuration closely enough that findings transfer to production, and it is isolated and controlled enough that aggressive or destructive tests can be executed without harming production systems or exposing real data.
A gaming marketplace is designing security tests at component test level for a single service that parses uploaded item-description files. Which test is characteristic of the component test level in security testing?
Malformed and unexpected item-description files are supplied directly to the parsing component's interface to observe how it handles them
Correct. One component, addressed through its own interface, exercised in isolation is the component test level.
A seller uploads an item description through the storefront, and the whole publication workflow is followed through to the public listing page
This exercises the assembled system through the business workflow, which belongs to the system or acceptance level.
The parsing component and the media-conversion component are exercised together to check that the data they exchange is validated on both sides
Two components exercised through their mutual interface is the component integration level, not the component level.
The deployed marketplace is scanned from outside the network to enumerate the services and versions it exposes
This examines the deployed system as a whole from an external position and is not a component-level activity.
At component level the test object is one component in isolation, addressed through its own interface. Sending malformed and unexpected input directly to that component's interface to see how it handles it is a typical component-level security test.
In a ride-hailing platform, three components exchange data over internal HTTP calls: the matching service, which picks a driver for a request; the pricing service, which returns the fare for a route; and the trip-ledger service, which stores the completed trip and its amount. The documented security risk analysis and the threat model state that the highest-rated internal threat is a manipulated fare value being accepted by the trip ledger, because pricing responses are consumed without re-validation, and that the pricing service currently trusts any caller inside the cluster. The test lead has to design security tests at the component integration test level. Which test design fits that level and those inputs?
Exercise the internal interfaces directly: send the trip ledger a fare value that no pricing response produced, and call the pricing service from a component that has no business reason to call it, requiring the receiving component to reject both
Correct. The tests act on the interfaces between the components, and they are derived from the two highest-rated threats named in the risk analysis and threat model.
Send malformed route payloads to the pricing service's own interface and observe whether the service crashes or returns an unhandled error
This is a component-level test of the pricing service in isolation. It does not address whether the ledger validates what pricing sends it.
Book a trip through the passenger app, complete it in the driver app and confirm that the receipt shown to the passenger matches the amount in the trip ledger
This validates a security-relevant outcome through the complete business process, which places it at the system or acceptance level rather than at component integration.
Review the source of the three services for places where an HTTP response body is deserialised without checking the declared content type
A static examination of the code can find candidate weaknesses, but it is not a test at the component integration level and does not demonstrate the interface behaviour.
Generate 5 000 concurrent matching requests and measure whether pricing responses begin to time out, forcing the ledger onto its fallback fare
This examines behaviour under load and the fallback path; it does not test whether a manipulated or unauthorised fare is accepted, which is the rated threat.
Component integration testing exercises the interfaces between components, guided by the documented risk analysis and threat model. The right design here injects manipulated and unauthorised traffic on the internal interfaces between matching, pricing and ledger, and verifies that the receiving component validates what it receives, rather than testing one component alone or the whole business flow end to end.
A security standard adopted by a real-estate platform contains both mandatory (normative) and optional (informative) clauses. What does that distinction mean when the standard is used in security testing?
Normative clauses have to be satisfied for conformance and become obligatory test conditions, while informative clauses give guidance that may inspire tests without conformance depending on them
Correct. Only the normative part determines conformance; the informative part explains and recommends.
Normative clauses apply when the standard is imposed by regulation, and informative clauses apply when it is imposed by contract
Regulatory versus contractual application concerns why the standard is binding on the organisation, which is a separate distinction from normative versus informative clauses.
Normative clauses describe security controls, while informative clauses describe the test techniques used to verify those controls
Both kinds of clause can address controls or techniques. The distinction is about obligation, not about subject matter.
Normative clauses are the ones the platform has tailored to its own context, and informative clauses are the untailored remainder
Tailoring is something the adopting organisation does. The normative or informative status of a clause is set by the standard itself.
Normative clauses state what must be satisfied for conformance and therefore become obligatory test conditions. Informative clauses provide explanation and guidance; they may inspire useful tests, but non-conformance to them is not a conformance failure.
A gaming marketplace lets players buy an in-game currency and trade items for it. A static analysis run and a design review produced four confirmed weaknesses in the currency service: reliance on client-side validation of the currency amount, insufficient session expiration after logout, missing rate limiting on the item-trade endpoint, and verbose error messages in the currency-transfer API. The security test lead now has to turn each weakness into concrete test cases, and decides to consult a catalogue of attack patterns. The table below records the intermediate result of that work.
How is a catalogue of attack patterns such as CAPEC applied at this point in the work, and what does it contribute that the list of weaknesses alone does not?
It supplies the attack patterns, with their prerequisites and variants, by which each weakness is actually exploited, so every weakness can be turned into executable attack scenarios and their expected technical impact
Correct. The attack-pattern catalogue bridges from a stated weakness to the concrete steps an attacker takes, which is exactly what a test case needs.
It supplies the numerical severity of each weakness, so the four items can be ranked and the two with the highest score tested first
Scoring severity is the job of CWSS or CVSS. An attack-pattern catalogue describes how an attack proceeds, not how severe it is.
It supplies the list of publicly reported vulnerability entries for the product versions in use, so the team learns which of the four weaknesses have already been reported by others
Publicly reported vulnerability entries are CVE records for concrete products. They do not describe generalised attack patterns.
It supplies the remediation guidance for each weakness, so the test cases can verify that the recommended fix has been implemented as prescribed
Verifying a prescribed fix is confirmation testing against the change. The attack-pattern catalogue exists to describe attacks, and the tests here are needed before any fix exists.
It supplies the threat categories under which the weaknesses can be grouped, so the team can check whether every category is represented in the test set
Systematic categorisation of threats is what a model such as STRIDE provides. An attack-pattern catalogue is more specific: it details how individual attacks are carried out.
CWE-style weakness information says what is wrong in the product. CAPEC describes the attack patterns by which such a weakness is exploited, so it supplies the attacker steps, prerequisites and variants that a test case needs. That turns a known weakness into concrete, executable attack scenarios rather than a statement of a coding flaw.
A municipal library is threat modelling its new city-services portal with STRIDE. The portal lets residents reserve books, pay parking fines and download their own borrowing history as a PDF; the download is generated by a single synchronous worker that holds the request open while it renders. During the workshop the team records two facts. First, the PDF download is addressed by a URL that contains the borrower number and no other check, so a resident who edits the number receives another resident's history. Second, the render worker accepts an unbounded date range, and a request covering 40 years occupies the worker for roughly 90 seconds while all other download requests queue behind it. Which two STRIDE categories do these two facts belong to, in the order given? (Choose two.)
The editable borrower number in the download URL is Information Disclosure, because data is exposed to someone not entitled to see it
Correct. STRIDE classifies a breach of confidentiality, where information reaches a party that should not have it, as Information Disclosure.
The unbounded date range occupying the single render worker is Denial of Service, because a cheap request makes the function unavailable to others
Correct. Denial of Service covers threats to availability, including resource exhaustion caused by a legitimate-looking request.
The editable borrower number is Spoofing, because the requester effectively presents themselves as the other borrower
Spoofing means falsely claiming an identity in order to be authenticated as it. Here the requester stays logged in as themselves; no identity claim is faked, the authorization check is simply absent.
The unbounded date range is Tampering, because the attacker modifies the parameters of the request that the worker processes
Tampering concerns unauthorised modification of data or code that the system relies on. Supplying a wide but valid range does not alter stored data; the harm is to availability.
The editable borrower number is Elevation of Privilege, because the resident obtains a capability normally reserved for library staff
Elevation of Privilege means gaining a higher privilege level than assigned. The resident keeps ordinary privileges and merely reaches data of a peer, which is a confidentiality breach.
The unbounded date range is Repudiation, because the portal cannot prove afterwards which resident submitted the expensive request
Repudiation is about the inability to attribute an action to its author. Nothing in the facts states that attribution is missing; the stated effect is on availability.
The unchecked borrower number in the URL lets one resident read another resident's data, which is Information Disclosure: a confidentiality breach. The unbounded date range lets a single cheap request monopolise the only render worker so that legitimate requests cannot be served, which is Denial of Service: an availability breach.
A connected-car supplier uses an industry security standard as the test oracle for its telematics unit: whatever the standard prescribes becomes the expected result. The current edition of that standard was written when the unit had one wired diagnostic port and a single cellular modem. The product now also carries a short-range wireless link to the driver's phone, accepts over-the-air firmware updates from a cloud service, and exposes a companion-app API through which a user can unlock the doors remotely. The test manager wants to keep using the standard but is asked to state its drawbacks in this situation. Which drawback is the most significant one to raise?
Interfaces the standard does not foresee, such as the wireless link, the over-the-air update path and the remote unlock API, yield no expected results, so conformance can be complete while the newest attack surface stays untested
Correct. An oracle can only produce expected results for what it addresses, so gaps in the standard become silent gaps in coverage.
The standard has to be applied exactly as published, so the supplier is not permitted to add tests of its own beyond the prescribed set
Standards are intended to be tailored to the context and supplemented. Nothing prevents additional tests; the difficulty is that the standard does not point to them.
Using a standard as the oracle produces more findings than the team can process, because a consensus document is written to cover every conceivable product
The problem in this scenario is under-coverage of new interfaces, not an excess of findings; and a standard's breadth does not by itself inflate finding counts.
Conformance to the standard cannot be demonstrated to a regulator or a customer unless an accredited external body executes the tests
Who executes the tests is a question of accreditation arrangements. It is not a drawback of using the standard as an oracle for a product that has outgrown it.
A standard describes defences against typical attacks, so the supplier would have to start test design from scratch for the diagnostic port and the modem as well
The opposite holds: for the interfaces the standard does cover, it spares the team from starting from a blank page. That is one of its benefits.
A standard is a consensus document and therefore lags the technology it describes. Where it is used as the oracle, anything the standard does not foresee, in this case the wireless link, the over-the-air update path and the remote unlock API, generates no expected result and so no test. Full conformance can be reached while the newest and most exposed interfaces stay uncovered.
A real-estate platform operates in two countries. In the second country a data localisation rule came into force this year: personal data of residents, including identity documents uploaded by landlords, must be stored and processed exclusively on infrastructure located in that country, and must not be transferred abroad even temporarily. The platform's engineering and test teams sit in the first country and have always tested against a shared staging environment there, restored weekly from a masked copy of the full production database. What is the correct consequence of this regulation for the security testing?
Tests that process the regulated residents' data must be executed in an in-country environment on data that never leaves the country, while the existing shared environment may keep serving the parts of the platform outside the rule's scope
Correct. The rule constrains the location of processing, so it partitions the test environments and test data rather than the test techniques.
Masking the personal data in the weekly restore is sufficient, because masked records are no longer personal data and may therefore continue to cross the border
Masking reduces exposure but does not by itself remove the data from the regulation's scope, and the rule as stated forbids transfer of the data outright.
The regulation concerns the production deployment only, so the test environments and the test data may stay exactly as they are
A test environment holding or processing the regulated data is covered as well; a regulation on processing location does not stop at the production boundary.
The identity documents must be removed from the test scope altogether, since they can no longer be made available to the test team in a lawful way
Excluding the most sensitive asset leaves its protection unverified. The lawful route is to test it in country, not to stop testing it.
The consequence is limited to the reporting side: findings about residents' data must be filed in a separate in-country defect tracker, while execution stays unchanged
Where findings are recorded is a genuine consideration, but it does not resolve the problem that the execution itself would process regulated data abroad.
The regulation constrains where the regulated data may exist and be processed, which directly constrains where tests touching that data can run and what data they may use. Tests exercising the localised data need an in-country environment and in-country test data; the existing cross-border staging environment can only continue for data outside the rule's scope.
A donation platform has no security testers of its own. It contracts an external supplier to perform the security testing of each quarterly release. The supplier's staff have no accounts in the platform's issue tracker, no access to the architecture wiki and no visibility of the internal security risk analysis; they receive a URL, a scope statement and a test window of five working days. The platform's test manager must decide how to adjust the security test process to this arrangement. Which adjustment addresses the organisational situation most directly?
Agree before the engagement which artefacts and accesses the supplier receives, including the risk analysis and threat model, and define how their findings are transferred into the platform's own risk handling and retesting
Correct. The two things outsourcing changes are the supplier's information position and the route their findings take back into the organisation, and both have to be arranged explicitly.
Keep the supplier without internal information on purpose, so that their findings reflect what a real outside attacker could achieve unaided
An uninformed external view has value, but adopting it as the whole approach means the internally known highest risks are never targeted and grey-box or white-box coverage is lost entirely.
Extend the test window from five to ten working days, so that the supplier can rediscover the information the internal team already holds
More time partly compensates for missing information, but paying the supplier to rediscover known facts is inefficient and still leaves the findings without a route into internal risk handling.
Require the supplier to test only the public donation pages, since the internal services cannot be described to an external party
Narrowing the scope to what needs no explanation leaves the internal services untested and treats an information-sharing question as a scoping limit.
Have the supplier deliver their report directly to the platform's board, so that the findings receive attention without passing through the engineering organisation
Escalating a report changes who reads it, not whether the findings are actionable or how they enter the risk register and the retest cycle.
Outsourcing the testing to a party that is outside the organisation changes what the testers can know and reach. The process therefore has to define, before the engagement, which artefacts and accesses the supplier is granted, and how their findings flow back into the platform's own risk handling. Without that, the supplier is forced into a purely external view and the findings never reach the internal risk register.
A city services portal, operated by the municipality and used for parking permits, library accounts and waste-collection bookings, is reviewed after its edge network intrusion detection system raised an unusual alert pattern. Between 09:20 and 10:00 on a Tuesday the NIDS recorded roughly 980 DNS query events attempting to resolve names such as vpn, mail-old, staging, backup and admin under the municipality's domain, together with about 575 probes whose packet characteristics match a known operating-system fingerprinting signature. All of these events originate from one source range, 203.0.113.0/24. Baseline traffic from every other source stays flat throughout. No authentication attempt, no data transfer and no service outage is recorded in the same window.
The security test lead analyses the scenario. Which two conclusions are justified? (Choose two.)
This is the active phase of information gathering: unlike passive collection from public sources, the attacker sends traffic to the municipality's own systems, which is precisely why it appears in the NIDS log at all
Correct. DNS enumeration and OS fingerprinting interact with the target, so they are detectable; passive gathering from search engines, social media and public records leaves no trace on the target side.
The testing response is to establish what this reconnaissance would find: which hosts under the domain are actually resolvable and reachable, including forgotten and non-production ones, and how much platform and version information the exposed services reveal
Correct. The observed activity is mapping the attack surface, so the tests should measure the same attack surface from the same position.
Since no authentication attempt and no data transfer were recorded, the pattern is best explained as a misconfigured internal monitoring job and needs no test response
The absence of an attack step is expected during reconnaissance and is not evidence of a benign cause; the traffic comes from one external range and matches a fingerprinting signature.
The activity is passive information gathering, because the portal's own data was never read and the municipality suffered no loss during the window
Passive versus active is determined by whether the attacker interacts with the target, not by whether damage occurred. Sending DNS queries and probes to the target's systems is active.
The 40-minute concentration of events shows a denial-of-service attempt against the portal's name resolution, so availability tests should be the priority
The volumes involved are small and the record shows no outage; the queries enumerate names rather than exhaust the resolver.
Because the source range is known, the correct test response is to confirm that traffic from 203.0.113.0/24 is blocked at the edge and to close the analysis there
Blocking one range addresses the observed source, not what the reconnaissance revealed. The attacker can reappear from elsewhere, and the exposed attack surface stays unmeasured.
DNS enumeration and OS fingerprinting are active reconnaissance: the attacker sends traffic to the target's own systems and therefore leaves traces in the target's logs, unlike passive information gathering from public sources, which produces no such traces. Because the activity maps the reachable names and platforms rather than attacking them, the reasonable test response is to verify what that mapping would reveal, namely forgotten or non-production hosts under the domain and the exposure of platform and version information.
An online marketplace for game items has been unavailable four times in seven weeks. Each incident follows the same shape. The item-trade and in-game currency services are flooded from a large, changing set of consumer broadband addresses spread over many countries; the flood begins between 19:40 and 20:10 local time, which is the marketplace's daily traffic peak, and it stops after 50 to 70 minutes. No account is compromised, no item or currency balance is altered, nothing is exfiltrated, and no message demanding payment is received before, during or after any of the four incidents. Comparing the dates with the market, the security analyst notes that each incident falls on a day when a competing marketplace launched a discount campaign, and that no incident occurred on any other day. The analyst has to characterise the likely nature of the attack and derive what to test. Which two conclusions are best supported? (Choose two.)
The absence of any ransom demand and of any theft, combined with timing on the competitor's campaign days at the traffic peak, points to a denial-of-service attack motivated by commercial damage rather than by direct financial gain from the marketplace
Correct. The motivation has to be inferred from what the attacker does and does not do: no extortion, no data theft, but maximum revenue loss at a moment that benefits a competitor.
Tests should reproduce this profile against the trade and currency endpoints, verifying how the platform behaves and degrades under a distributed flood at peak load, and whether the detection and protective measures react to it in time
Correct. The derived tests target the availability of the specific endpoints attacked, under the load profile observed, and cover the effectiveness of the countermeasures.
The absence of a ransom demand shows the flood is a side effect of legitimate demand spilling over from the competitor's campaign, so the correct response is capacity planning rather than security testing
Legitimate demand would not arrive as a flood from a changing set of unrelated consumer addresses against two specific endpoints, nor stop abruptly after about an hour.
The wide geographic spread of consumer broadband addresses indicates an insider acting from within the marketplace's own network, using employee credentials to generate the traffic
An insider operates from inside the perimeter with granted access; the observed traffic comes from a large external set of addresses and uses no credentials at all.
Because nothing was stolen or altered, the incidents affect availability only and therefore fall outside the scope of security testing, which addresses confidentiality and integrity
Availability is a security property in its own right, and denial-of-service scenarios are explicitly within the scope of security testing.
The repetition on four separate occasions indicates an unskilled attacker running a downloaded tool at random, so the testing effort should concentrate on well-known published weaknesses of the marketplace software
The timing is anything but random: it aligns with the daily peak and with a competitor's campaign days, which indicates deliberate target selection rather than opportunistic tool use.
The pattern points to an availability attack whose purpose is commercial: there is no extortion demand and no theft, but the outages land precisely when they cost the marketplace the most revenue and divert players to a competitor's campaign. Distribution across many consumer addresses is characteristic of a botnet used to generate the flood. The testing that follows should measure the platform's behaviour under exactly that load, at peak, and check that protective and detection measures act on the affected endpoints.
An agritech company moves its platform development to a DevOps model and adopts DevSecOps practices. What is the main effect of this on the security testing?
Security test activities are shifted earlier and embedded in the delivery pipeline, so that security feedback arrives with each change rather than in a phase before release
Correct. Shift-left and pipeline integration are the defining effects of a DevOps or DevSecOps model on security testing.
Security testing becomes the responsibility of the operations team, since it is operations that runs the pipeline and the production environment
DevSecOps distributes security responsibility across development, security and operations rather than transferring it to one of them.
Only automated security tests remain in scope, because a pipeline stage cannot accommodate manual analysis or exploratory work
Manual analysis, threat modelling and penetration testing continue to be needed; they are scheduled alongside the pipeline instead of inside every run.
The security test process is unaffected, because the lifecycle model determines the release cadence and not the content of the security tests
The lifecycle model changes when, how often and by whom security test activities are performed, so the process does change.
In a DevOps model security testing is shifted left and embedded in the delivery pipeline, so that security feedback arrives with every change instead of in a phase at the end. Activities that cannot be automated are still needed, but they are planned around the continuous flow.
A university has run its student portal in production for six years without functional changes in the last nine months. Why does security testing still have to continue during operations and maintenance?
New weaknesses become known in the components and platforms the portal relies on, and the environment and its configuration change, so an unchanged system can still become vulnerable
Correct. Security risk depends on the state of the outside world as much as on the code, so testing continues after release.
The findings from before release lose their validity after a fixed period, so the same test set has to be re-executed to renew the previous results
Results do not expire on a schedule. Retesting is driven by changes in the system, its environment or the known threats, not by the age of a report.
Security testing in production is the only way to obtain realistic data volumes, which is why it is deferred to the operations phase
Realistic volumes can be arranged in a test environment, and testing before release is not deferred for that reason.
Operational security testing exists to measure the response times of the portal under authentication load, which cannot be observed before go-live
This describes a performance concern. It is not the reason security testing continues during operations and maintenance.
The threat landscape changes independently of the software. New weaknesses become publicly known in the components and platforms in use, and the environment and configuration drift, so a system that has not changed can nevertheless become vulnerable and needs continued security testing.
A ride-hailing platform has been in production for four years. A third-party image-processing library, used to accept and transform the driver documents and vehicle photos that riders and drivers upload, is upgraded from version 2.4 to version 3.1 to remove a publicly known weakness in its handling of malformed files. The library's own release notes state that the new major version also tightens metadata parsing, changes the default maximum decoded image size, and replaces the loader used for one of the supported formats. Nothing else in the release changes. The test lead has to determine the security regression test set. What should it contain?
Confirmation tests for the specific weakness, plus regression tests over the upload and transformation paths for every supported format, malformed and oversized inputs against the new decoded-size default, and the surrounding validation, size-limit and error-handling behaviour
Correct. It separates confirmation of the fix from regression coverage of the security-relevant behaviour the new major version could have altered.
Confirmation tests for the specific weakness only, because the rest of the platform's code was not modified and therefore cannot have changed behaviour
The behaviour that matters is the platform's behaviour, and a new major version of a library it depends on changes that behaviour even with untouched application code.
The complete security test set of the platform, including the payment, matching and trip-ledger services, so that nothing is left unverified after a dependency change
Re-running everything ignores the analysis of what the change can affect; it consumes the available window without improving the coverage of the actual risk.
Regression tests over the driver and rider registration workflows, verifying that documents can still be uploaded and displayed and that no upload fails after the upgrade
This is functional regression of the happy path. It shows the feature still works but exercises none of the security-relevant behaviour the new version changed.
A software composition analysis run over the platform's dependency tree, confirming that version 3.1 is installed and that no component with a known weakness remains
This verifies which version is deployed, which is inventory evidence. It does not test how the platform now behaves on malformed, oversized or unusual-format uploads.
Confirmation testing shows the specific weakness is gone. Security regression testing must then cover the security-relevant behaviour that the change could have disturbed: the upload and transformation paths for every supported format, including the format whose loader was replaced, malformed and oversized inputs against the new size default, and the checks that surround the library, such as file-type validation, size limits and error handling, which may behave differently now.
A connected-car supplier develops the telematics software of a vehicle platform in two-week iterations. Each iteration produces a potentially releasable increment, and the team demonstrates it on a bench vehicle. Software reaching real vehicles, however, is released only once a quarter, through a regulatory approval window: the candidate build is frozen six weeks before the window, submitted to a type-approval process, and only then distributed over the air. In practice, therefore, an increment finished in iteration 1 reaches vehicles about four months later, while iterations 2 to 6 continue to build on it. The test manager analyses how this gap between iteration cadence and release cadence affects security test planning. Which analysis is correct?
Security testing must run inside each iteration and be repeated as a planned re-assessment of the frozen candidate during the freeze-to-release interval, because weaknesses becoming known in that interval cannot be absorbed by the frozen build and the next ordinary release is a quarter away, so an explicit route for post-freeze findings is required
Correct. It identifies both cadences as necessary and locates the risk precisely in the interval where the build is fixed but the threat landscape is not.
Because vehicles receive software only quarterly, the security testing should be planned as a single campaign before each approval submission, which avoids repeating the same tests six times per quarter
Concentrating security testing at the end removes the early feedback that makes weaknesses cheap to fix, and five iterations of work would be built on an unverified increment.
The gap is a documentation matter: the iteration test reports need to be consolidated into the submission package, and no change to the security test planning itself is required
Consolidating evidence is necessary for the submission but does nothing about the security-relevant changes occurring between the freeze and the release.
Since each iteration produces a potentially releasable increment, the security test approach can be identical to that of a continuously deployed service, with the approval window treated purely as an administrative step
A continuously deployed service can ship a fix within hours. Here a fix waits for the next window, which changes the consequences of a late finding and therefore the planning.
The principal risk is that the bench vehicle differs from production vehicles, so the security test planning should concentrate on acquiring a fleet of representative vehicles for each iteration demonstration
Environment representativeness is a real concern, but it is not the effect of the gap between iteration and release cadence that the question asks about.
The iteration cadence and the release cadence serve different purposes here. Security testing inside each iteration keeps the increment verifiable while it is cheap to change, but the security-relevant state of the world moves during the four months to release: new weaknesses become publicly known in the included third-party components and in the platform, and the frozen candidate cannot absorb them. The principal risk therefore lies in the freeze-to-release interval, which needs its own planned re-assessment and a defined route for handling a weakness discovered after the freeze, since the next ordinary opportunity is a quarter away.
How do the acceptance criteria agreed for security testing influence the work of the security test team?
They state what has to be demonstrated and to what degree, which determines the approaches and techniques capable of producing that evidence and forms the basis for the exit criteria
Correct. Acceptance criteria drive the selection of approach and technique, because a criterion is only useful if some technique can show it is met.
They fix the number of security test cases to be executed per release, so that test progress can be reported as a percentage
Counting test cases is a progress metric. An acceptance criterion expresses a required property of the object, not a quantity of tests.
They determine who signs the security test report, since acceptance is a formal decision taken outside the test team
Who accepts is a matter of roles and authority. The criteria themselves describe what acceptance requires.
They apply to the acceptance test level only, so they influence the final test level and leave the earlier levels unaffected
Agreed criteria for security testing shape the approach across the levels, since evidence for them is gathered well before acceptance testing.
Acceptance criteria state what has to be demonstrated and to what degree before the object is considered acceptable. That determines which test approaches and techniques can supply the required evidence, and it forms the basis of the exit criteria.
A ride-hailing company operates an information security management system (ISMS). What do the results of its security testing contribute to that ISMS?
Measured evidence of which risks are actually present and how effective the implemented controls are, so that security risks can be managed on facts rather than on assumptions
Correct. The ISMS manages risk continuously, and test results are the empirical input that keeps its risk picture accurate.
The definition of the ISMS scope, since the systems that were tested are the systems the ISMS covers
The ISMS scope is set by management on the basis of assets and obligations; it is not derived from whatever happened to be tested.
The evidence needed to close the ISMS certification audit, after which the results have served their purpose
Supporting an audit is one use, but treating results as certification paperwork misses their continuing role in active risk management.
The security policy text itself, because each finding is written up as a new policy clause for the ISMS document set
Findings can motivate policy changes, but they are not policy text, and turning each finding into a clause is not how results feed an ISMS.
Security test results give the ISMS factual, measured evidence about which risks are actually present and how effective the implemented controls are, so that the security risks can be managed actively rather than on the basis of assumptions.
An agritech company wants its ISMS to measure the contribution of security testing. Which two of the following are useful measures for that purpose? (Choose two.)
The proportion of identified security risks for which security tests exist and have been executed
Correct. This links testing to the ISMS risk register and exposes risks that nothing is verifying.
The time taken between the identification of a vulnerability and its confirmed closure, per severity
Correct. It measures how long the organisation remains exposed, which is a genuine attribute of its security posture.
The number of security test cases written by the test team per iteration
This counts output volume. A large number of test cases can still leave the significant risks uncovered.
The number of hours the test team spent on security testing during the reporting period
Effort describes cost, not the level of protection reached or the coverage achieved.
The number of different security testing tools in operation across the development teams
Tool count describes the tool landscape. More tools do not imply better coverage of the risks that matter.
Useful ISMS measures describe how well risks are covered and how quickly identified weaknesses are dealt with, because both statements say something about the security posture. Measures of test-team activity volume, or of effort spent, describe work performed rather than security achieved.
A university has run an ISMS for three years. Every quarter, the same automated scan of the same 12 student-facing web applications is executed, the same report template is filled in, and the report is filed with the ISMS. The findings are almost identical each quarter, the risk register has not been amended since the second quarter of the first year, and no risk has ever been re-rated or closed on the basis of a test result. Reports are formally delivered on time. The test manager is asked to raise the maturity of the ISMS specifically by introducing new testing approaches. Which proposal does that?
Add threat modelling of the 12 applications and introduce techniques the scan cannot perform, such as testing of authorization logic and of abuse of the business processes, then feed those findings into a re-rating of the risk register
Correct. These are different approaches, not merely more of the same, and they generate the new information the ISMS needs in order to re-assess its risks.
Extend the same automated scan to the 30 remaining internal applications, so that the ISMS covers the full application landscape
This adds test objects and improves coverage, which is worthwhile, but it is the same approach applied more widely rather than a new approach.
Increase the scan frequency from quarterly to monthly, so that the ISMS receives results three times as often
More frequent execution of an unchanged scan yields the same findings sooner. It does not produce information the ISMS does not already have.
Replace the report template with an ISMS dashboard showing the finding counts per application and per quarter as a trend
Better presentation may improve visibility, but the underlying findings are unchanged, so the risk picture stays as stale as before.
Require the head of each faculty to countersign the quarterly report, so that the findings are formally acknowledged by the business owners
Adding a signature step strengthens formal accountability without adding any new testing, which is what was asked for.
Maturity can be raised through new test objects, better coverage, or new test approaches. Here the request is specifically for new approaches: adding threat modelling of the applications and techniques the current scan cannot perform, such as testing of authorization logic and business-process abuse, produces findings the repeated scan structurally cannot produce, and therefore new information that forces the risk register to be revisited.
Why does the criticality of security test results affect how those results are handled and communicated?
A finding usually describes a weakness that is also present in production, so the report is exploitable information and its distribution and tracking have to be controlled
Correct. The report is a description of how to attack the live system, which is why access to it is restricted.
Security findings are reported without technical detail, so that no reader of the report can reproduce the problem described
The people who have to fix and retest a finding need the technical detail. The answer is controlled access, not the removal of the detail.
Security findings are recorded outside the defect management process, because a weakness is not a defect and cannot be assigned to a developer
Security findings are managed as defects, in a protected tracker; they are assigned, fixed and retested like other defects.
The criticality determines the language of the report, so that critical findings are written for a technical audience and minor ones for management
Reports are tailored to their audience regardless of criticality; severity does not decide which audience a finding is written for.
A security finding usually describes a weakness that also exists in the running production system, so the report is itself exploitable information. Distribution therefore has to be controlled, and the tracking of such findings kept protected, until the weakness has been closed.
On a real-estate platform, a scan of the landlord portal returns one finding with no severity value and no impact statement, only this description: the endpoint that returns a listing's document bundle accepts a document identifier supplied by the caller and does not verify that the identifier belongs to a listing owned by the requesting landlord. The test engineer must evaluate the result and determine the technical impact before the finding is reported. Which action produces that determination?
Exercise the endpoint with an ordinary landlord account against identifiers of another landlord's listings, establish what is returned and whether the same route also permits changes, and state the impact in terms of the assets reached
Correct. The technical impact follows from what the weakness actually yields in this system, which has to be established by exercising it and examining the result.
Look up the standard severity rating published for this class of weakness and record it as the technical impact of the finding
A generic rating for a class of weakness ignores what this endpoint returns and which assets it exposes, which is exactly what the impact statement has to express.
Re-run the scan with the deepest configuration profile available, so that the tool itself supplies the missing severity and impact fields
A deeper scan may find more items, but the tool is reporting a description precisely because it cannot judge the business meaning of the documents behind the endpoint.
Inspect the source of the endpoint to confirm that the ownership check is missing, and report the absent check as the technical impact
Confirming the check is absent establishes the cause of the weakness. The impact is what an attacker gains from it, which the code alone does not state.
Ask the landlord-portal product owner how damaging unauthorised access to document bundles would be for the business, and record that assessment
That is a business impact judgement, useful for prioritisation, and it still rests on an unestablished technical picture of what is actually reachable.
Determining the technical impact means establishing what an attacker can actually achieve through the weakness in this system. That requires exercising it: retrieving documents of another landlord's listing with an ordinary account, then examining what those documents contain and whether the same route also permits changes, so the impact can be stated in terms of the assets reached.
An agritech platform has a confirmed weakness in the field-device management service: a diagnostic endpoint returns the full configuration of any sensor, including its access token, to any authenticated user of the platform. Two options are on the table. Option A changes the reverse proxy configuration so that the diagnostic path is no longer routed from the internet; the endpoint itself is untouched and still answers requests received from inside the cluster, and any component or service that can reach the service directly still obtains the tokens. Option B changes the service code so that the endpoint verifies that the caller administers the sensor concerned, and removes the token from the response body altogether. The team must choose and must justify the choice in terms of vulnerability closure. What is the correct assessment?
Option A hides the vulnerability, because the weakness persists and stays exploitable from any position that reaches the service; Option B removes it. A may serve as a temporary mitigation, and the finding stays open until B is delivered
Correct. It distinguishes hiding a vulnerability from removing it and assigns the configuration change its proper role as an interim measure.
Both options close the vulnerability, so Option A should be chosen because it can be deployed without a code change and without a new release of the service
Only Option B removes the weakness. Treating a routing change as equivalent closure is exactly the confusion between hiding and removing that the assessment has to avoid.
Option A is the stronger measure, because a change at the reverse proxy protects every endpoint of the service at once, whereas Option B fixes only the one endpoint found
Breadth at the perimeter does not compensate for leaving the weakness in place; the tokens remain retrievable by anything inside the cluster.
Neither option closes the vulnerability, since the sensor tokens have already been exposed and the only closure is to rotate every token on all field devices
Token rotation is a necessary incident response step, but it does not stop the endpoint from exposing the new tokens the same way; Option B does address the weakness.
Option B is unnecessary once Option A is applied and monitoring is added to the diagnostic path, because an attempt to reach the endpoint would then be detected and investigated
Detection tells the operator an attempt occurred; it does not prevent an internal caller from obtaining the tokens, so the weakness is still there.
Option A hides the vulnerability: the weakness remains in the product and stays exploitable from any position that reaches the service, so the closure depends entirely on an external configuration remaining as it is. Option B removes the vulnerability by eliminating the cause. A is acceptable only as a temporary mitigation while B is implemented, and the finding stays open until B is in place.
Within the usual categorisation of security testing tools, how is interactive application security testing (IAST) characterised?
It instruments the application and observes its internals while the running application is exercised, combining internal visibility with dynamic execution
Correct. Internal instrumentation plus observation during execution is what distinguishes IAST from static and from purely black-box dynamic tools.
It analyses the source code without executing it, reporting the code locations that match its rule set
That describes static application security testing. IAST needs the application to run.
It sends crafted requests to a deployed application from outside and judges the responses, with no visibility of the internals
That describes dynamic application security testing in its black-box form; IAST specifically adds internal visibility.
It resolves the dependency tree of the build and matches the identified components against catalogues of known weaknesses
That describes software composition analysis, which examines the components used rather than the behaviour of the running application.
IAST instruments the application and observes it from the inside while it is being exercised. It therefore combines internal visibility with dynamic execution, which places it between the purely static and purely black-box dynamic categories.
A municipal library is selecting a security testing tool for its city-services portal. Which consideration is specific to security testing tools and should therefore weigh in the decision?
How frequently the supplier updates the tool's detection content, since the known weaknesses and attack techniques it has to recognise change continuously
Correct. A security tool whose detection content is stale reports against yesterday's threat landscape, which makes update cadence a primary criterion.
Whether the tool can also detect memory leaks and other resource-management defects, so that one tool serves both security and general testing
General-purpose defect detection is not what a security testing tool is selected for, and breadth of that kind does not improve its security coverage.
Whether the tool's user interface is available in the languages spoken by the portal's residents
Interface localisation matters for the portal itself, not for a tool used internally by the test team.
Whether the tool stores its findings in the same database product the portal already uses, so that no new technology is introduced
Uniform infrastructure is a general procurement preference and says nothing about the tool's ability to find security weaknesses.
The value of a security testing tool depends on how current its detection content is, because the threats and known weaknesses it must recognise change continuously. How frequently the supplier updates that content, and whether updates will keep coming, is therefore a central selection criterion.
A connected-car supplier must security test a telematics control unit it bought from a subcontractor. The subcontractor delivers the signed firmware binary and an interface description, but contractually withholds the source code and the build. The unit exposes a diagnostic protocol over the vehicle bus and a cellular data channel, and the supplier's own requirement is to observe how the unit behaves while it is running, including when it receives input it was not designed for. Which two tool categories fit this situation? (Choose two.)
Fuzzing tools, to submit malformed and unexpected messages to the diagnostic protocol and the cellular channel of the running unit
Correct. Fuzzing needs only an interface and a running target, and it directly serves the requirement to observe behaviour on input the unit was not designed for.
Dynamic analysis tools, to exercise the unit through its exposed interfaces while it runs and observe its behaviour and responses
Correct. Dynamic tools work against the deployed, running object without needing its source, which matches both constraints.
Static application security testing tools, to examine the unit's source code against a rule set of insecure coding patterns
The source code is contractually withheld, so a source-based static tool has nothing to analyse.
Software composition analysis tools, to resolve the unit's dependency tree from its build manifests and match the components against known weaknesses
Composition analysis of this kind relies on build manifests or lock files from the build, which the subcontractor does not provide.
Interactive application security testing tools, to instrument the unit's code and report weaknesses observed from inside it while it runs
Instrumentation requires the ability to build or modify the application. The firmware is delivered signed and closed, so it cannot be instrumented.
Without source code and without a build, source-based static analysis is not applicable. What remains are dynamic, black-box or grey-box categories: fuzzing tools to submit malformed and unexpected input to the diagnostic protocol and the data channel, and dynamic analysis tools that exercise the running unit through its exposed interfaces and observe its behaviour and responses.