Sicurezza nei software di elaborazione genomica: minacce e misure di protezione

Security in genomic processing software rests on one premise: a genome cannot be reissued after a breach, so protection must be designed into the pipeline rather than added around it. That means threat modelling across the whole lifecycle, isolation of datasets and processes, encryption in transit and at rest, strict access control, continuous monitoring, and contractual and jurisdictional clarity wherever cloud providers or third-party integrations touch the data.

Vicedomini Softworks

Build Security Into Every Processing Pipeline

Vicedomini Softworks engineers secure custom software with cloud-native infrastructure, Zero Trust security, monitoring and ongoing support.

Ask for a consultation

TL;DR

Genomic data is immutable, identifying and shared with relatives, so a breach has consequences that no password reset can undo.
The main processing threats are re-identification through quasi-identifiers, membership and attribute inference, ransomware and integrity attacks on pipelines, and adversarial attacks on genomic AI models.
Defence in depth, dataset isolation, supply-chain checks, audited access, tested backups and verified deletion form the baseline set out by GA4GH and NIST.
Homomorphic encryption and secure multi-party computation help, but their computational and communication overheads limit where they can be applied.
Cloud use and integrations require checks on data-centre location, logging, encryption, breach-reporting terms and deletion certificates, under the law of each jurisdiction involved.

Why genomic data needs its own security model
Threats that affect genomic data during processing
Safeguards across collection, analysis, storage and sharing
Encryption and privacy-preserving analysis
Cloud infrastructure and third-party integrations
Standards and legal requirements by jurisdiction
Monitoring and incident response
Perspective
How Vicedomini Softworks can support a secure build
FAQ
Sources

Why genomic data needs its own security model

Genomic information differs from ordinary personal data in ways that affect software architecture directly. NIST states that the combined intrinsic properties of genomic data distinguish it from other data types, raising cybersecurity and privacy concerns that current policies, guidance documents and technical controls address inadequately. The same publication, NIST IR 8432 from December 2023, remains the most useful single framing of the problem for engineering teams.

Three properties matter most. The first is immutability: the NCCoE genomic threat modelling project describes genomic data as immutable personal information, which makes predictability, manageability and disassociability difficult to achieve. A compromised password is replaced; a compromised genome is compromised permanently. The second is scale: the same NCCoE material notes that the size and compute requirements of genomic analysis make it hard to guarantee the confidentiality, integrity and availability of computing environments. The third is the number of parties involved, since researchers, healthcare providers and third-party vendors all touch the data, which is why NCCoE argues for methodical threat modelling across the product or environment lifecycle.

The commercial context raises the stakes. Academic work published in the Journal of Biomedical Informatics argues that, given the growing commercialisation of DNA technologies and the sensitivity of the data, a security-by-design approach is required, because bio-cyber threats to genomic data and software applications can affect confidentiality, integrity and availability alike. A review in Nature Reviews Genetics adds that growth in health care, research and direct-to-consumer collection has increased the volume of genomic data collected, used and shared, with new privacy implications both legally and technically.

Threats that affect genomic data during processing

The threat landscape divides into attacks on people, through their data, and attacks on systems, through their availability and integrity. Both reach software teams, because the controls that address them live in code, configuration and architecture.

Attacks on individual privacy

A 2025 article in Discover Computing catalogues the main families: identity tracing using quasi-identifiers, inference attacks, completion attacks that exploit family similarities, machine-learning re-identification and adversarial attacks on genomic AI models. Identity tracing uses attributes such as age, sex and location to re-identify people in datasets that were nominally de-identified. Inference attacks, including attribute disclosure and membership inference, reveal sensitive traits or establish that a person took part in a particular study.

Two historical cases show why de-identification alone fails. A 2024 scoping review recounts that in 2018 researchers re-identified an anonymous female study participant by name, matching her genetic data to a genealogy database and deducing her surname from relatives who had uploaded their own data. The same review reports that in 2009 researchers found a genetic predisposition to Alzheimer disease in the public genome of James Watson, even though he had withheld certain parts of the data. The lesson for software design is that the privacy of one person depends on what their relatives and public databases disclose, which no single system controls.

Attacks on systems and the organisation

NIST IR 8432 describes attacks aimed at genomic data that threaten the economy through theft of biotechnology intellectual property, disrupt biopharmaceutical and agricultural output through integrity attacks, and use availability attacks such as ransomware encryption, data deletion or disabling of automated equipment. It also lists individual harms: intimidation for financial gain, discrimination based on disease risk, and privacy loss through revealed consanguinity or inferred traits.

Sequencers deserve separate attention. The Discover Computing authors observe that genomic technologies such as sequencers are often connected IoT devices with limited processing, memory and power, and are therefore exposed through their internet connectivity. A pipeline is only as strong as its least defensible component, and that component is frequently an instrument or a laboratory integration rather than the analysis code.

Threat	Mechanism	Primary control in software
Identity tracing	Quasi-identifiers linked to public or genealogical data	Minimised metadata, controlled access to linkable fields
Membership and attribute inference	Statistical queries over aggregate results	Query auditing, output restrictions, privacy-preserving analysis
Ransomware and deletion	Availability attack on storage and compute	Isolated backups, tested disaster recovery, network segmentation
Integrity attack	Tampering with sequences or pipeline outputs	Signed artefacts, checksums, immutable audit logs
Adversarial attack on AI models	Crafted inputs or model inversion	Input validation, model access control, monitoring
Instrument compromise	Weak connected sequencer or laboratory device	Segmentation, patching, restricted egress

The Global Alliance for Genomics and Health publishes a Data Security Infrastructure Policy, DSIP v4.0, which is the most operational reference available. Its operational assurance requirements include defence-in-depth assurances such as process and dataset isolation to prevent interference and side-channel attacks, code security and supply-chain checks, backups and disaster recovery, jurisdiction-aligned retention, and safe data destruction. The policy also states that any processor using a third party to store or process genomic or health data must ensure the business agreement obliges that party to provide physical and environmental protection.

Translated into engineering practice, these obligations shape each stage of the lifecycle.

Collection

Security begins at ingestion. Instrument integrations, upload endpoints and consent metadata should be authenticated, validated and logged, and fields that are not needed for analysis should never enter the system. Minimisation at this stage reduces what can later be traced, inferred or leaked.

Analysis

Analysis environments need strict isolation between projects, tenants and datasets. This is where multi-tenant design choices matter: shared compute without hard boundaries invites the side-channel and interference risks that DSIP v4.0 names explicitly. Supply-chain verification of workflow engines, containers and libraries is equally important, since bioinformatics pipelines routinely compose many third-party components.

Storage

Encryption at rest, key management separated from data custody, backups that survive ransomware, and retention rules that follow the governing jurisdiction form the storage baseline. Deletion must be real: backups and replicas are in scope.

A notable architectural pattern is to avoid copying data at all. The AnVIL platform, described in Cell Genomics, inverts the traditional sharing model by having researchers work on the data inside cloud computing resources instead of downloading it. The same article reports that AnVIL is FedRAMP-certified and compliant with NIST 800-53, implements GA4GH DRS for data access, and relies on OIDC and OAuth2 standards with GA4GH Passports for authentication and authorisation. Bringing computation to the data keeps copies few and auditing centralised.

Encryption and privacy-preserving analysis

Encryption in transit and at rest is mandatory, but processing is where data is most exposed, because analysis normally requires plaintext. Privacy-preserving techniques address that gap, with trade-offs that should be understood before they are specified.

Homomorphic encryption allows computation on encrypted data without decryption, supporting outsourced statistical operations such as allele frequency calculation and regression modelling. The Discover Computing authors note, however, that its computational overhead makes it impractical for large-scale or real-time genomic analysis, and that secure multi-party computation, which avoids exposing individual data points, carries high computation and communication costs that limit scalability.

Earlier evidence from the NIH-funded iDASH competition quantifies the burden. A 2016 BMC Medical Genomics review reported that secure computation can enable comparative analysis of human genomes, yet homomorphic methods used up to several gigabytes of memory, while secure multi-party computation needed to transmit multiple gigabytes of data to analyse sequences of length 100K. Costs have evolved since then, but the pattern holds: these techniques suit well-defined, high-value computations, such as cross-institution statistics, rather than every pipeline stage.

A practical architecture therefore layers controls: conventional encryption and hardened isolation for bulk processing, with privacy-preserving computation reserved for the narrow operations where raw data must not be exposed to the processing party.

Encryption and privacy-preserving analysis

Cloud infrastructure and third-party integrations

Cloud adoption is driven by compute and cost, but the Discover Computing authors caution that outsourcing genetic information to cloud services makes it vulnerable to cyber-attacks. The question is not whether to use cloud infrastructure but what must be verified when doing so.

A 2022 checklist in Human Genome Variation recommends that organisations investigate data-centre security, disaster prevention and response measures, confirm the country or region where data is hosted, check customer-accessible logs and encryption in transit and at rest, and verify complete deletion, including deletion methods and certificates. Earlier legal and ethical guidance in the European Journal of Human Genetics adds that organisations should ask whether a provider will show ISO 27001 or ISO 27002 documentation, whether it supports multi-factor authentication, automatic session timeouts and audit logging, and whether it commits to report data losses or breaches within a short period, for example under 24 hours.

Integration points deserve the same discipline. Each API, message queue or file exchange between a laboratory system, an analysis platform and a clinical or research application is a trust boundary. Mapping those boundaries in a structured model is the heart of lifecycle threat modelling, and guidance on medical data annotation under EU rules illustrates how compliance-sensitive data handling is tied to workflow design. Zero Trust principles, with every request authenticated and authorised regardless of network position, suit this environment well.

Standards and legal requirements by jurisdiction

Genomic security obligations differ by country, and an article read worldwide should attribute each rule to its origin. Nature Reviews Genetics summarises the landscape: the EU GDPR, effective since 2018, restricts handling of personal information including genetic data, grants access and deletion rights, and imposes security and breach-notification requirements. China tightly regulates and requires government approval for the export of human genomic data, and the United States lacks an overarching national data privacy policy and does not typically limit genomic data export. The same source reports that Italy’s Privacy Code requires genetic, biometric and health-related processing to follow EDPB best practices and demands a data privacy impact assessment and ethics committee assessment before health-related processing. Separate work on multisite research states that Italy’s Privacy Code is congruent with the GDPR on anonymisation and pseudonymisation.

On the technical side, NIST has identified gaps across the lifecycle: in genomic data generation, safe sharing, monitoring of systems that process genomic data, specific guidance for genomic processors, and policy on national security and privacy threats. NIST’s draft IR 8467, dated 16 December 2024, responds with a joint CSF 2.0 and Privacy Framework 1.0 Community Profile, a structured, risk-based approach to cybersecurity and privacy risk in genomic data processing. For organisations new to risk-based selection of controls, a primer on NIST-based AI risk assessment shows how the framework functions translate into testing priorities, which is relevant where genomic AI models are in scope.

Which regime governs a given system depends on where the data subjects live, where the data is hosted and who the controller is. That determination belongs at the start of the architecture, not at the audit.

Standards and legal requirements by jurisdiction

Monitoring and incident response

Security that is not observed degrades. NIST IR 8432 describes the Risk Management Framework of SP 800-37 Revision 2 as a structured process covering preparation, categorisation, control selection, implementation, assessment, authorisation and continuous monitoring, with organisations expected to track both threats and outstanding vulnerabilities to determine risk.

GA4GH DSIP v4.0 is more prescriptive. It states that each processor should engage an independent third party for penetration testing at least annually and must have documented procedures for monitoring system activity, detecting threats and vulnerabilities, and notifying potential security incidents. On breaches involving potentially identifiable data, the processor must report expeditiously to the data controller, and the controller must in turn report expeditiously to the affected data subjects.

Centralised architectures simplify this. The AnVIL authors note that, in a federated cloud model, centralised intrusion detection and auditing can be far more detailed for protected datasets, supplemented by active threat detection. In practice, observability must cover who accessed which dataset, which workflow ran on it, and where outputs went, and the incident plan must name who notifies the controller and the data subjects, and within what time under the applicable law.

Perspective

Our experience in engineering secure, multi-tenant and cloud-native systems leads us to one conclusion: in genomic software, the architecture is the security policy. Controls that depend on users behaving correctly eventually fail, whereas isolation, least privilege and auditable data flows enforced by the platform continue to hold.

We therefore treat threat modelling as a first deliverable, before the first feature. It determines tenant boundaries, where keys live, which integrations are trusted and what must be logged. Because our clients work directly with the engineers who design and maintain the system, with no account-manager layer in between, a decision such as moving analysis to the data rather than moving data to the analyst is made by the people who will build and operate it, and its consequences are visible to the business at once.

Our stack, which includes Java and Jakarta EE, Spring Boot and Quarkus, Kubernetes and Red Hat OpenShift, combined with Zero Trust practice, infrastructure automation and production monitoring, is suited to this kind of work. Every consulting engagement ends with a written recommendation, and we limit the number of simultaneous projects so that security reviews receive the attention they need.

Pepe F.

How Vicedomini Softworks can support a secure build

Organisations modernising a genomic pipeline, integrating laboratory systems or auditing existing code can begin with a bounded engagement. Our initial assessment starts from €3,500 one-off and produces a written view of architecture and technical risk.

Vicedomini Softworks

For continuing oversight, the CTO Advisory plan starts from €1,800 per month, Fractional CTO from €4,000 per month and CTO Partner from €7,500 per month, all described on the CTO subscription page. Code audits, architecture and stack selection, AI and automation, custom development and staff augmentation are described under our software services.

FAQ

Not by itself. Research shows that people can be re-identified from quasi-identifiers such as age, sex and location, and from genealogy databases that include their relatives. Safe sharing combines minimised metadata, controlled access, auditing and, where appropriate, analysis performed where the data sits.

Does encrypting genomic data solve the problem?

Encryption at rest and in transit is essential, but data is normally decrypted during analysis. Homomorphic encryption and secure multi-party computation can protect data in use, though their computational and communication overheads currently restrict them to specific, well-defined operations.

What should be checked before moving genomic workloads to the cloud?

The data-centre location, security and disaster-response measures, customer-accessible logs, encryption in transit and at rest, breach-reporting commitments and deletion certificates. Provider documentation such as ISO 27001 policies should be requested, and the legal regime of each jurisdiction involved should be confirmed.

Which framework should guide a genomic security programme?

NIST IR 8432 and the draft IR 8467 profile give a risk-based structure, while GA4GH DSIP v4.0 sets operational assurances for processors. Legal duties, such as GDPR obligations in the EU, apply on top of these and depend on where the data subjects and the data are located.