Map project to CNCF FSUG questionnaire

[mlieberman85]

The CNCF FSUG questionnaire is meaningful to finserv groups when evaluating open source projects for use. It would be useful to answer the questions.

[mlieberman85]

https://github.com/cncf/financial-user-group/blob/master/projects/fsug-checklist/fsug-checklist.md

[mlieberman85]

Notes for the questionnaire:

Access control model:

• Root: Not for SSF deployment, however certain builds might require root but up to the operators on how to administer those permissions
• Privileged access: Yes, for SPIFFE/SPIRE and Admission Control.

Auditing:

• Permissions: Defined in and managed by configuration. Git is the source of truth
• Output: Outputs like logs, artifacts, attestations get sent to appropriate data store like log aggregation, artifact storage, or metadata storage. This is customizable by the end user
• Backups: This would be backed up like any normal k8s service but the source of truth for configuration should be in Git
• Logs: This follows k8s standards so normal k8s log forwarding/aggregation should work
• The system is largely stateless outside of previous pipeline run metadata that should be archived similarly to logs. Configuration should be source of truth. We have controls in place to try to prevent people from changing configuration that isn't stored in source control

IAM integration

• Centralized Directory integration: We follow standard k8s permissions
• Local users: By default we create some service accounts in k8s for operation but this could be configured to be other mechanisms
• Authentication: K8s defaults. Note: an upstream system we use Tekton dashboard, currently does not allow IAM at this point so any user with permission to the dashboard would be able to see all pipeline runs. This is being addressed with the team upstream.

Continuous Delivery/Code Promotion and Release

• Promotion process: Yes, we support promotion of different build pipelines and allow flexibility up to the end user, they can build it out as needed as per policy and their needs. Code will follow normal Git processes and it is up to the end user to control access.
• SBOM: Yes, for top level dependencies. We are working on transitive
• Provenance for all dependencies: No, we have SLSA1 and 2 provenance for some.

Code Review:

• Two person code review from maintainers of the project.
• All reviewers must have MFA enabled as well as contributors

Release:

• Pipeline: We suggest using an older version of SSF to build and deploy newer version. We do suggest end users provide other automated and manual controls to ensure any gaps in existing versions of SSF can be adequately addressed.

Release:

• Deployment Pipeline: We recommend following existing CD processes for deploying k8s services, e.g. ArgoCD, GitOps, etc.
• Recommendations: Keep everything in configuration. Hot fixes should be addressed like anything else. Since SSF is a system on k8s only k8s resources that have changed should be deployed

Documentation for Dev and Ops

• Documentation for dev yes, ops there is some but more need to be worked on.

Network Dependencies

• Inside the SSF itself the SSF resources don't usually need to talk to each other directly and use controllers and other k8s mechanisms
• For SSF communicating to other network dependencies like source code control, metadata storage and artifact storage you should apply appropriate security policies. If those things are stored within k8s, you can follow procedures for sharing secrets or giving access to service accounts, etc. Outside of k8s it's recommended you follow your enterprises IAM best practices and where possible follow CNCF security best practices.

Observability

• Currently we don't do anything additional for providing hooks into observability outside of any functionality provided in the components of the SSF itself

Data Classification and Policy

• Encryption: We follow normal k8s mechanisms and also most of the data flowing through the system is also signed as well

Compliance

• Threat Modeling: Not Yet, we do plan to when it makes sense
• Control Mapping: Not yet, but it is on the backlog

Governance

• Steering governance: Right now nothing, but as we transition to OpenSSF we will follow the supply chain integrity WG's governance model
• Vuln disclosure policy: Same as above
• Release process: We haven't had an official release yet, but we will create a process with the first release
• Code Review Process: Two maintainers need to sign off and it must pass all tests and linting
• Changes to Governance: Changes to governance will follow OpenSSF governance guidelines