Research collected from outside sources and what this site derives from them; every fact links to a saved copy of its source Research or story?
GRC · Risks · Stakeholders · Frameworks · The graph · Explore · Gaps · From the network
What the risk graph is missing
The graph shows what is joined; this page shows what is not. Each gap below is a rule, written as data in data/grc-gaps.json, computed over the 713 nodes and 1418 edges at every release: a control no test reaches, code nobody owns, a risk no story tells, a join an agent inferred that nobody has checked. Each names who could close it; each item opens in the explorer.
95controls joined to no code or test that implements them (of 95)16code with no owner one step away (of 16)9code no test reaches (of 16)14risks no story tells (of 34)0risks with no treatment (of 34)0risks with no owner (of 34)0vulnerabilities no test reaches (of 2)815edges inferred by an agent, not yet checked (of 1418)
Controls joined to no code or test that implements them: 95 of 95
A security requirement with nothing that implements or exercises it. Today every control is joined only through the risks it governs, so none is shown to be implemented or tested. Looks at every control for a path to test or code within 3 steps through tests, realised_in, located_in, implemented_by. Who could close it: GRC desk.
The 95, each opening in the explorer
- CIS Controls 13.10: Perform application layer filtering
- CIS Controls 16.4: Establish and manage an inventory of third-party software components
- CIS Controls 2.2: Ensure authorised software is currently supported
- CIS Controls 7.4: Perform automated application patch management
- CIS Controls 7.7: Remediate detected vulnerabilities
- CISA KEV and BOD 22-01 BOD22-01: Federal agencies remediate catalogued vulnerabilities by the due date set
- CISA KEV and BOD 22-01 KEV-entry: A CVE enters the catalogue on reliable evidence of active exploitation
- Cyber Essentials FW: Firewalls: boundary protection for internet-facing services
- Cyber Essentials SUM: Security update management: high and critical updates within 14 days of release; unsupported software removed
- Cyber Resilience Act AnnexI.II: Vulnerability handling requirements: identify components, remedy without delay, publish fixed vulnerabilities, coordinated disclosure
- Cyber Resilience Act Art.13: Obligations of manufacturers, including due diligence on integrated third-party and open-source components
- Cyber Resilience Act Art.14: Reporting an actively exploited vulnerability: early warning within 24 hours to the CSIRT and ENISA
- Cyber Resilience Act Art.24: Obligations of open-source software stewards
- DORA Art.10: Detection of anomalous activities
- DORA Art.11: Response and recovery, including ICT business continuity
- DORA Art.19: Reporting major ICT-related incidents
- DORA Art.28: Managing ICT third-party risk
- DORA Art.8: Identification of ICT assets, their dependencies and the risks to them
- EU AI Act Art.15: Accuracy, robustness and cybersecurity of high-risk AI systems
- EU AI Act Art.50: Transparency: content generated by AI is disclosed as such
- EU AI Act Art.55: Providers of general-purpose models with systemic risk: evaluate, mitigate systemic risks, report serious incidents, protect cybersecurity
- FIRST TLP 2.0 TLP:AMBER+STRICT: Limited disclosure: recipients share only within their organisation
- GDPR Art.24: Responsibility of the controller: measures appropriate to the risk
- GDPR Art.28: Processors: the controller uses only processors that give sufficient guarantees
- GDPR Art.32: Security of processing, including a process for regularly testing and evaluating it
- GDPR Art.33: Notifying a personal data breach to the supervisory authority within 72 hours
- GDPR Art.34: Communicating a high-risk personal data breach to the people affected
- GDPR Art.5(1)(f): Integrity and confidentiality: personal data processed with appropriate security
- ISO/IEC 27001 6.1.2: Information security risk assessment: identify risks and their owners
- ISO/IEC 27001 A.5.14: Information transfer, including under agreed classification
- ISO/IEC 27001 A.5.21: Managing information security in the ICT supply chain
- ISO/IEC 27001 A.5.24: Incident management planning and preparation
- ISO/IEC 27001 A.5.29: Information security during disruption
- ISO/IEC 27001 A.5.30: ICT readiness for business continuity
- ISO/IEC 27001 A.5.5: Contact with authorities
- ISO/IEC 27001 A.5.7: Threat intelligence
- ISO/IEC 27001 A.8.16: Monitoring activities
- ISO/IEC 27001 A.8.20: Network security
- ISO/IEC 27001 A.8.25: Secure development life cycle
- ISO/IEC 27001 A.8.29: Security testing in development and acceptance
- ISO/IEC 27001 A.8.8: Management of technical vulnerabilities
- ISO/IEC 27001 A.8.9: Configuration management
- ISO/IEC 29147 and 30111 29147:coordination: Coordinating disclosure with other vendors and parties under embargo
- ISO/IEC 29147 and 30111 29147:receipt: Receiving vulnerability reports and acknowledging the finder
- ISO/IEC 29147 and 30111 30111:handling: Investigating, remediating and releasing the fix, and learning from it
- ISO/IEC 42001 6.1.2: AI risk assessment
- ISO/IEC 42001 6.1.3: AI risk treatment
- MITRE ATT&CK T1190: Exploit public-facing application
- MITRE ATT&CK T1595.002: Active scanning: vulnerability scanning
- NIS2 Art.12: Coordinated vulnerability disclosure and the European vulnerability database
- NIS2 Art.20: Governance: management bodies approve and oversee the risk-management measures and can be held liable
- NIS2 Art.21(2)(c): Business continuity, backup management, disaster recovery and crisis management
- NIS2 Art.21(2)(d): Supply chain security, including the security of each direct supplier
- NIS2 Art.21(2)(e): Security in acquisition, development and maintenance, including vulnerability handling and disclosure
- NIS2 Art.23: Reporting significant incidents: early warning in 24 hours, notification in 72 hours, final report in a month
- NIST AI RMF GOVERN-6.1: Policies address AI risks from third-party entities
- NIST AI RMF MANAGE-2.4: Mechanisms exist, with assigned responsibility, to supersede, disengage or deactivate an AI system
- NIST AI RMF MEASURE-2.7: AI system security and resilience are evaluated and documented
- NIST CSF 2.0 DE.CM-01: Networks and network services are monitored to find potentially adverse events
- NIST CSF 2.0 GV.RM-01: Risk management objectives are established and agreed by stakeholders
- NIST CSF 2.0 GV.RR-01: Leadership is responsible and accountable for cybersecurity risk
- NIST CSF 2.0 GV.SC-05: Supply chain requirements are established and integrated into contracts
- NIST CSF 2.0 GV.SC-07: Supplier risks are understood, recorded, prioritised, assessed, responded to and monitored
- NIST CSF 2.0 ID.AM-02: Inventories of software, services and systems are maintained
- NIST CSF 2.0 ID.RA-01: Vulnerabilities in assets are identified, validated and recorded
- NIST CSF 2.0 ID.RA-02: Threat intelligence is received from information sharing forums and sources
- NIST CSF 2.0 ID.RA-08: Processes for receiving, analysing and responding to vulnerability disclosures are established
- NIST CSF 2.0 PR.PS-02: Software is maintained, replaced and removed commensurate with risk
- NIST CSF 2.0 RC.RP-01: The recovery portion of the incident response plan is executed
- NIST CSF 2.0 RS.CO-03: Information is shared with designated internal and external stakeholders
- NIST SP 800-53 CM-8: System component inventory
- NIST SP 800-53 CP-2: Contingency plan
- NIST SP 800-53 IR-6: Incident reporting
- NIST SP 800-53 RA-5: Vulnerability monitoring and scanning
- NIST SP 800-53 SA-22: Unsupported system components
- NIST SP 800-53 SC-7: Boundary protection
- NIST SP 800-53 SI-2: Flaw remediation
- NIST SP 800-53 SI-4: System monitoring
- NIST SSDF PW.7: Review and analyse human-readable code to find vulnerabilities
- NIST SSDF PW.8: Test executable code to find vulnerabilities
- NIST SSDF RV.1: Identify and confirm vulnerabilities on an ongoing basis
- NIST SSDF RV.2: Assess, prioritise and remediate vulnerabilities
- NIST SSDF RV.3: Analyse vulnerabilities to identify their root causes
- OWASP Top 10s A03:2025: Software supply chain failures
- OWASP Top 10s A06:2021: Vulnerable and outdated components
- OWASP Top 10s LLM01:2025: Prompt injection
- OWASP Top 10s LLM02:2025: Sensitive information disclosure
- OWASP Top 10s LLM06:2025: Excessive agency
- OWASP Top 10s LLM09:2025: Misinformation
- PCI DSS 12.10.1: An incident response plan exists and is ready to be activated
- PCI DSS 6.3.1: Security vulnerabilities are identified, risk-ranked and managed
- PCI DSS 6.3.3: Critical security patches are installed within one month of release
- PCI DSS 6.4.2: An automated technical solution that detects and prevents web attacks protects public-facing web applications
- SOC 2 CC7.1: Detection and monitoring procedures identify new vulnerabilities and configuration changes
- SOC 2 CC9.2: Risks from vendors and business partners are assessed and managed
Code with no owner one step away: 16 of 16
A file that matters to a risk with nobody named against it. Looks at every code for a path to stakeholder or member or role within 1 step. Who could close it: GRC desk.
The 16, each opening in the explorer
- .github/workflows/pages.yml
- Zend/zend_alloc.c
- Zend/zend_execute_API.c
- Zend/zend_hash.c
- Zend/zend_string.c
- Zend/zend_types.h
- admin/build/release.sh
- admin/build/security_check.py
- admin/build/validate.py
- admin/factcheck/fc.py
- admin/security/injection-allowlist.json
- data/claims.json
- ext/session/session.c
- main/SAPI.c
- main/main.c
- main/rfc1867.c
Code no test reaches: 9 of 16
Changed or named code with no test joined through its remediation. Looks at every code for a path to test within 2 steps through realised_in, tests. Who could close it: dev@php.newsroom.
Risks no story tells: 14 of 34
A risk on the register that no story on the site explains to a reader. Looks at every risk for a path to story within 1 step. Who could close it: Journalist.
The 14, each opening in the explorer
- A compromise becomes a reportable breach
- A status word stronger than its evidence
- A vault key or token published
- Councils and police offline without saying why
- Early mitigation advice to a few providers leaked
- Essential and financial entities miss their reporting clocks
- Manufacturers under the Cyber Resilience Act owe a 24-hour report
- Mass scanning and mutated payloads after the leak
- PHP-FPM deployments wrongly treated as safe or as certainly vulnerable
- Personal data taken from a compromised PHP application
- Popular applications compromised before authentication
- Prompt injection through captured material
- Several finders, one small team
- This newsroom's own agents are steered, leak or mislead
Risks with no treatment: 0 of 34
A risk with nothing recorded that reduces it. Looks at every risk for a path to treatment within 1 step. Who could close it: GRC desk.
None: every one reaches it.
Risks with no owner: 0 of 34
A risk nobody holds. Looks at every risk for a path to stakeholder or role within 1 step through owned_by. Who could close it: GRC desk.
None: every one reaches it.
Vulnerabilities no test reaches: 0 of 2
A flaw whose fix nobody can show is tested. Looks at every vulnerability for a path to test within 2 steps. Who could close it: dev@php.newsroom.
None: every one reaches it.
Edges inferred by an agent, not yet checked: 815 of 1418
A join an agent made that nobody has checked against a source, the code or a person. Who could close it: GRC desk.
| Verb | Edges | Example |
|---|---|---|
tests | 232 | Zend/tests/oom_SplFixedArray___unserialize.phpt tests Allocations that may fail instead of abort |
governed_by | 139 | Remote code execution on internet-facing PHP serve governed_by ISO/IEC 27001 A.8.8: Management of technical vulne |
part_of | 76 | The PHP project part_of Everyone with PHP in the path |
shown_on | 58 | Remote code execution on internet-facing PHP serve shown_on The two flaws |
arises_from | 51 | The allocator's longjmp-based bailout on out-of-me arises_from CVE-2026-109618: RCE via OOM corruption |
tracked_by | 45 | The editor tracked_by Dinis Cruz |
protected_by | 41 | Remote code execution on internet-facing PHP serve protected_by Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 |
owned_by | 40 | Remote code execution on internet-facing PHP serve owned_by Organisations running PHP |
told_in | 26 | Remote code execution on internet-facing PHP serve told_in Where php2shell stands: many sites dark, millions |
treated_by | 24 | Remote code execution on internet-facing PHP serve treated_by The PHP project |
borne_by | 22 | Remote code execution on internet-facing PHP serve borne_by People who use PHP services |
informed_by | 15 | Remote code execution on internet-facing PHP serve informed_by Agencies and CERTs |
concerns | 12 | The coordinated disclosure broke before the fix wa concerns CVE-2026-109618: RCE via OOM corruption |
raised_by | 11 | The coordinated disclosure broke before the fix wa raised_by The finders |
briefed_by | 9 | Board and executives briefed_by Board member or executive |
located_in | 8 | Agents that read the open web and can publish located_in admin/build/release.sh |
regulated_by | 6 | Patched builds published before the embargo lifted regulated_by The PHP security team |
A rule is a kind of node, what it should reach, within how many steps and through which verbs. Add one to the data and it appears here at the next release. A gap is not a fault: some are there by design (a control in a framework the fix commit was never meant to test); the page says where to look, not what to conclude.