Cybersecurity & safety

Security begins with evidence.

The question is not whether a security claim sounds convincing. It is whether the evidence can withstand inspection.

Security claims must survive inspection.

Cybersecurity is not a property that can be added at the end of a release. It is a discipline of making assumptions explicit, identifying what can fail, and testing whether a system behaves safely when those assumptions are wrong. JAKASII approaches security as an engineering problem with evidence at its centre.

Every meaningful security decision begins with scope. What assets matter? Who might act against them? Which boundaries must hold? A threat model is not a document written for compliance; it is the shared description that allows developers, reviewers, and operators to reason about risk before a change reaches production.

A proposed change should be treated as a hypothesis, not a verdict. The implementation may be elegant and still weaken an access boundary, expose sensitive data, or introduce a dependency risk. Security work therefore needs acceptance criteria that are clear enough to be checked by someone other than the person or system that made the change.

Independence matters. A system should not be allowed to declare its own work secure on the basis of its own explanation. We are studying verification paths in which the change, the evidence, and the decision can be examined separately—through review, controlled tests, policy checks, and reproducible execution.

Reproducibility turns a claim into something that can be revisited. A useful record identifies the version examined, the files changed, the commands run, the environment assumptions, and the observed result. That record does not guarantee that software is safe; it makes the reasoning available for audit, challenge, and improvement.

Software supply chains require the same discipline. Components, build inputs, and release artifacts each carry risk when their origin or integrity cannot be established. Provenance is therefore not administrative overhead: it is the connection between a released artifact and the code, dependencies, and process that produced it.

Testing must reflect more than whether a feature works on its expected path. Security-oriented testing asks what happens at boundaries, under invalid input, across changes in privilege, and when dependencies or configurations are altered. Automated checks are valuable, but they are only as useful as the questions they are designed to ask.

Operations complete the security picture. Logs, alerts, vulnerability handling, incident response, and responsible disclosure are ways of learning from residual risk after release. A secure development process is not one that promises no defects; it is one that can identify, contain, explain, and correct them without concealing the evidence.

Our research also considers how AI systems and agents can assist this work without becoming an unreviewed authority. They may help organise evidence, propose tests, or surface inconsistencies, but consequential decisions remain bounded by policy, independent checks, and human judgement. The aim is not automated certainty. It is a more rigorous and accountable way to build and maintain software.