Marcela S. Melara

Eman Abu Ishgair, Chinenye Okafor, Marcela S. Melara et al.

Software Bills of Materials (SBOMs) have become a regulatory requirement for improving software supply chain security and trust by means of transparency regarding components that make up software artifacts. However, enterprise and regulated software vendors commonly wish to restrict who can view confidential software metadata recorded in their SBOMs due to intellectual property or security vulnerability information. To address this tension between transparency and confidentiality, we propose Petra, an SBOM exchange system that empowers software vendors to interoperably compose and distribute redacted SBOM data using selective encryption. Petra enables software consumers to search redacted SBOMs for answers to specific security questions without revealing information they are not authorized to access. Petra leverages a format-agnostic, tamper-evident SBOM representation to generate efficient and confidentiality-preserving integrity proofs, allowing interested parties to cryptographically audit and establish trust in redacted SBOMs. Exchanging redacted SBOMs in our Petra prototype requires less than 1 extra KB per SBOM, and SBOM decryption accounts for at most 1% of the performance overhead during an SBOM query

Marcin Spoczynski, Marcela S. Melara, Sebastian Szyller

The rapid adoption of open source machine learning (ML) datasets and models exposes today's AI applications to critical risks like data poisoning and supply chain attacks across the ML lifecycle. With growing regulatory pressure to address these issues through greater transparency, ML model vendors face challenges balancing these requirements against confidentiality for data and intellectual property needs. We propose Atlas, a framework that enables fully attestable ML pipelines. Atlas leverages open specifications for data and software supply chain provenance to collect verifiable records of model artifact authenticity and end-to-end lineage metadata. Atlas combines trusted hardware and transparency logs to enhance metadata integrity, preserve data confidentiality, and limit unauthorized access during ML pipeline operations, from training through deployment. Our prototype implementation of Atlas integrates several open-source tools to build an ML lifecycle transparency system, and assess the practicality of Atlas through two case study ML pipelines.

Marcin Spoczynski, Marcela S. Melara

We present a security framework that strengthens distributed machine learning by standardizing integrity protections across CPU and GPU platforms and significantly reducing verification overheads. Our approach co-locates integrity verification directly with large ML model execution on GPU accelerators, resolving the fundamental mismatch between how large ML workloads typically run (primarily on GPUs) and how security verifications traditionally operate (on separate CPU-based processes), delivering both immediate performance benefits and long-term architectural consistency. By performing cryptographic operations natively on GPUs using dedicated compute units (e.g., Intel Arc's XMX units, NVIDIA's Tensor Cores), our solution eliminates the potential architectural bottlenecks that could plague traditional CPU-based verification systems when dealing with large models. This approach leverages the same GPU-based high-memory bandwidth and parallel processing primitives that power ML workloads ensuring integrity checks keep pace with model execution even for massive models exceeding 100GB. This framework establishes a common integrity verification mechanism that works consistently across different GPU vendors and hardware configurations. By anticipating future capabilities for creating secure channels between trusted execution environments and GPU accelerators, we provide a hardware-agnostic foundation that enterprise teams can deploy regardless of their underlying CPU and GPU infrastructures.

Marcela S. Melara, Mic Bowman

Deployed microservices must adhere to a multitude of application-level security requirements and regulatory constraints imposed by mutually distrusting application principals--software developers, cloud providers, and even data owners. Although these principals wish to enforce their individual security requirements, they do not currently have a common way of easily identifying, expressing and automatically enforcing these requirements at deployment time. CDI (Code Deployment Integrity) is a security policy framework that enables distributed application principals to establish trust in deployed code through high-integrity provenance information. We observe that principals expect the software supply chain to preserve certain code security properties throughout the creation of an executable bundle, even if the code is transformed or inspected through various tools (e.g., compilation inserts stack canaries for memory safety). Our key insight in designing CDI is that even if application principals do not trust each other directly, they can trust a microservice bundle to meet their security policies if they can trust the tools involved in creating the bundle.

Marcela S. Melara, Mic Bowman

As cloud providers push multi-tenancy to new levels to meet growing scalability demands, ensuring that externally developed untrusted microservices will preserve tenant isolation has become a high priority. Developers, in turn, lack a means for expressing and automatically enforcing high-level application security requirements at deployment time. In this paper, we observe that orchestration systems are ideally situated between developers and the cloud provider to address these issues. We propose a security policy framework that enables security-oriented orchestration of microservices by capturing and auditing code properties that are incorporated into microservice code throughout the software supply chain. Orchestrators can leverage these properties to deploy microservices on a node that matches both the developer's and cloud provider's security policy and their resource requirements. We demonstrate our approach with a proof-of-concept based on the Private Data Objects [1] confidential smart contract framework, deploying code only after checking its provenance.

Marcela S. Melara, Michael J. Freedman, Mic Bowman

Trusted executions environments (TEEs) such as Intel(R) SGX provide hardware-isolated execution areas in memory, called enclaves. By running only the most trusted application components in the enclave, TEEs enable developers to minimize the TCB of their applications thereby helping to protect sensitive application data. However, porting existing applications to TEEs often requires considerable refactoring efforts, as TEEs provide a restricted interface to standard OS features. To ease development efforts, TEE application developers often choose to run their unmodified application in a library OS container that provides a full in-enclave OS interface. Yet, this large-TCB development approach now leaves sensitive in-enclave data exposed to potential bugs or vulnerabilities in third-party code imported into the application. Importantly, because the TEE libOS and the application run in the same enclave address space, even the libOS management data structures (e.g. file descriptor table) may be vulnerable to attack, where in traditional OSes these data structures may be protected via privilege isolation. We present EnclaveDom, a privilege separation system for large-TCB TEE applications that partitions an enclave into tagged memory regions, and enforces per-region access rules at the granularity of individual in-enclave functions. EnclaveDom is implemented on Intel SGX using Memory Protection Keys (MPK) for memory tagging. To evaluate the security and performance impact of EnclaveDom, we integrated EnclaveDom with the Graphene-SGX library OS. While no product or component can be absolutely secure, our prototype helps protect internal libOS management data structures against tampering by application-level code. At every libOS system call, EnclaveDom then only grants access to those internal data structures which the syscall needs to perform its task.