# Supply Chain Integrity For Polkadot and Parachains

**URL:** <https://forum.polkadot.network/t/supply-chain-integrity-for-polkadot-and-parachains/2656>\
**Category:** Tech Talk\
**Tags:** frame\
**Created:** [April 20, 2023, 12:28am UTC](https://forum.polkadot.network/t/supply-chain-integrity-for-polkadot-and-parachains/2656 "2023-04-20T00:28:00Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![aliX](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/alix/32/651_2.png) [@aliX](https://forum.polkadot.network/u/aliX)\
**Post date:** [April 20, 2023, 12:28am UTC](https://forum.polkadot.network/t/supply-chain-integrity-for-polkadot-and-parachains/2656/1 "2023-04-20T00:28:00Z")

</div>

Even though Polkadot release process is following a strict standard to ensure the build is fully reproducible, there is still room for improving how the dependencies are referenced so any parachain or code that are built based on a particular version of Polkadot use the exact same dependency as used for that version of Polkadot. The current practice where in Cargo.toml Polkadot uses a branch of substrate as a dependency doesn’t seem to be aligned with production level releases. I’m referring to the lines such as:  
`frame-system = { git = "https://github.com/paritytech/substrate", branch = "polkadot-v0.9.41" }`  
Here if we had gone for a tag instead of a branch, we could be sure that the referenced code would fetch the same logic in subsequent builds. This is so we align the shipment with Hermetic and Reproducible principles of [SLSA 4](https://security.googleblog.com/2021/06/introducing-slsa-end-to-end-framework.html). Any reason why we are not doing this?
