Source code review, the static half.
DORA (Regulation (EU) 2022/2554) sets the principles; the regulatory technical standards on the ICT risk management framework, Commission Delegated Regulation (EU) 2024/1774, spell out the detail. Two of its articles land in a pull request. Article 16 covers ICT systems acquisition, development and maintenance: systems are tested and approved before use and after maintenance, and under Article 16(3) that procedure includes source code reviews covering both static and dynamic testing, with security testing for internet-exposed systems. The entity identifies and analyses vulnerabilities and anomalies in the source code, adopts an action plan to address them, and monitors that plan. Article 17 covers ICT change management: changes are recorded, tested, assessed, approved independently of whoever requested or implemented them, with fallback procedures and a separate path for emergency changes.
These are RTS articles, not the DORA Regulation's own Article 16 and 17. A pull request is where static review of the code happens most naturally, and where a change first shows what it actually does.
The shapes the same control failure takes.
For a financial entity's own code, the source-code-review and change-management duties meet in the diff. The recurring shapes:
A vulnerability reaches an internet-exposed system
A customer-facing API or portal gains an injection, path traversal or access-control flaw, the class of issue Art. 16(3) expects source code review and security testing of internet-exposed systems to identify.
A static check is removed from the procedure
The static analysis or code review step that the entity's testing procedure relies on is disabled, skipped for a repository, or made non-blocking, so the static half of source code review stops happening.
A finding is closed without an action
A vulnerability found in review is dismissed or silenced in code (an inline ignore, a baseline update) with no fix and no entry in the action plan Art. 16(3) asks the entity to adopt and monitor.
The approver is the implementer
A change is merged by the same person who wrote it, or an approval requirement is removed for a path, eroding the independence between approving and implementing that Art. 17 asks for.
The fallback goes missing
A change ships without the rollback, feature flag or migration down-step that the entity's change procedure relies on if the change fails.
A statement download that trusts the id.
A customer portal at a payment institution gets a new endpoint to download monthly statements. It checks that a customer is signed in, then loads the statement by the id in the URL. It works for every link the portal generates, and changing the number in the URL returns another customer's statement.
+ router.get("/statements/:id", requireCustomer, async (req, res) => {+ const s = await statements.findById(req.params.id);+ res.download(s.path);+ });The route confirms a customer is signed in but loads any statement by id, so one customer can download another's statements by changing the number in the URL, on an internet-exposed endpoint. Art. 16(3) expects vulnerabilities in the source code to be identified and analysed, and an action plan adopted and monitored to address them. Scope the lookup to the signed-in customer (findByIdForCustomer(req.params.id, req.customer.id)), and record the finding and its fix in the plan if it reached any environment.
Security reading of the same pull request
heygrc reviews this pull request against the RTS articles. Aevral, an AI security reviewer from the same company, reads the same diff for security flaws such as injection, path traversal and broken access control, and posts them as leads with evidence.
What that contributes: a static reading of each change it reads, one input to the static half of source code review under Art. 16(3). It posts at most two findings per review, so it is not the whole static review. The RTS also requires dynamic testing, an action plan for what is found, and monitoring of that plan; those stay with you, as does change approval under Art. 17.
Supervisors look for the procedure, and the plan it produces.
A competent authority or internal audit looking at Art. 16 and 17 asks for the documented testing procedure, how it covers static and dynamic testing and internet-exposed systems, and then for its output: the vulnerabilities it identified, the action plan adopted for them, and evidence the plan was monitored to closure. On change management they sample changes for the record, the independent approval, the fallback and, for emergency changes, the after-the-fact assessment. A statement endpoint that shipped to a customer portal with no ownership check and no static finding, or with a finding and no action, shows up as a gap in the first of those samples.
A review, not your testing programme.
heygrc flags changes that weaken source code review or change management and cites the article so the fix happens in the pull request. It does not run your dynamic testing, keep your action plan, or approve your changes. These pages are illustrative and do not determine how DORA or the RTS apply to your entity. Entities under the simplified ICT risk management framework follow Title III of the RTS instead.