Supported Standardization of Application Integration

[andrewg-xyz]

As Consumer of UDS Marketplace applications I want confidence in the security and functionality of applications So that I can Improve the accessibility of software for operational users

Acceptance Criteria

Given An application When engineering work is done to integrate with UDS Then there exists defined security standards And there exists documentation for these standards And there exists supporting Continuous Integration jobs to enforce these standards And there is defined required metadata for the application And there exists documentation for this metadata And there exists supporting Continuous integration jobs to enforce these requirements And there exists defined functional checkout of applications And there exists documented guidelines on suggested framework/s to perform functional checkout

- [ ] https://github.com/defenseunicorns/uds-marketplace/issues/87
- [ ] https://github.com/defenseunicorns/uds-marketplace/issues/82
- [ ] https://github.com/defenseunicorns/uds-marketplace/issues/84
- [ ] https://github.com/defenseunicorns/uds-marketplace/issues/85
- [ ] https://github.com/defenseunicorns/uds-marketplace/issues/89
- [ ] https://github.com/defenseunicorns/uds-marketplace/issues/58
- [ ] https://github.com/defenseunicorns/uds-marketplace/issues/63
- [ ] https://github.com/defenseunicorns/uds-marketplace/issues/23
- [ ] https://github.com/defenseunicorns/uds-common/pull/205
- [ ] https://github.com/defenseunicorns/uds-marketplace/issues/83
- [ ] https://github.com/defenseunicorns/uds-marketplace/issues/182

[corang]

I think we may hold off on the metadata piece for now, talking with @mike-winberry @marshall007 it's impossible to know what to put in it or if we actually need it until we have some semblance of a marketplace application built out

[corang]

@andrewg-xyz What do you mean by "functional checkout"?

[corang]

Who's responsible for defining "security standards"?

[andrewg-xyz]

I think we may hold off on the metadata piece for now, talking with @mike-winberry @marshall007 it's impossible to know what to put in it or if we actually need it until we have some semblance of a marketplace application built out

@corang I think it's okay to start with a few known factors

• name
• description
• version

how would we point UDS Marketplace to a registry and 'source' an application into the display? I think we could do it via a zarf package in an oci registry.

[andrewg-xyz]

@andrewg-xyz What do you mean by "functional checkout"? @corang "playwright tests" I feel pretty soft about this, how can we ensure application functionality? should we require healthz or readyz endpoints? testing of some sort?

[andrewg-xyz]

Who's responsible for defining "security standards"?

We are :) - but ultimately what our personas demand and desire. Similar to everything else. we can start with one or two simple obvious things (i.e. sboms and dependency check? for instance)

[corang]

@andrewg-xyz What do you mean by "functional checkout"? @corang "playwright tests" I feel pretty soft about this, how can we ensure application functionality? should we require healthz or readyz endpoints? testing of some sort?

For now id say playwright tests are a good start for apps that serve a web ui, I like the idea of implementing healthchecks if possible when the upstream chart doesn't

[marshall007]

Who's responsible for defining "security standards"?

We are :) - but ultimately what our personas demand and desire. Similar to everything else. we can start with one or two simple obvious things (i.e. sboms and dependency check? for instance)

@andrewg-xyz I feel pretty strongly that we cannot establish robust "security standards" across all package flavors. Chainguard's approach mitigates virtually all supply chain attacks, which is why we established that partnership in the first place. IMHO we should only put packages on the marketplace if they use images built by a party we trust.

Furthermore, this "trust" needs to be verifiable:

1. Images must be signed
2. Related artifacts like the zarf package configuration, SBOMs, test results, etc should be delivered as signed attestations
3. The package itself must be signed
4. Ideally "keyless signing" (a la sigstore.dev) is used so we can prove these artifacts were built in CI using our "trusted workflow" and not off someone's local

[andrewg-xyz]

Who's responsible for defining "security standards"?

We are :) - but ultimately what our personas demand and desire. Similar to everything else. we can start with one or two simple obvious things (i.e. sboms and dependency check? for instance)

@andrewg-xyz I feel pretty strongly that we cannot establish robust "security standards" across all package flavors. Chainguard's approach mitigates virtually all supply chain attacks, which is why we established that partnership in the first place. IMHO we should only put packages on the marketplace if they use images built by a party we trust.

Furthermore, this "trust" needs to be verifiable:

1. Images must be signed
2. Related artifacts like the zarf package configuration, SBOMs, test results, etc should be delivered as signed attestations
3. The package itself must be signed
4. Ideally "keyless signing" (a la sigstore.dev) is used so we can prove these artifacts were built in CI using our "trusted workflow" and not off someone's local

So much Yes! I agree with you :) - at one point we discussed only really supporting "unicorn" flavor for marketplace. I also thing the 4 items you mentioned are awesome and we should create tasks for each of those :)