You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[x] I have reviewed the TOC's moving level readiness triage guide, ensured the criteria for my project are met before opening this issue, and understand that unmet criteria will result in the project's application being closed.
Microcks Incubation Application
v1.6
This template provides the project with a framework to inform the TOC of their conformance to the Incubation Level Criteria.
Engage with the domain specific TAG(s) to increase awareness through a presentation or completing a General Technical Review.
A presentation to the TAG App Delivery was conducted on February 19, 2025 (19-02-2025), during the TAG General Meeting. The recording is available on the TAG YouTube channel here.
TAG members had no objections or specific recommendations, see: CNCF TAG App Delivery Meeting Notes; they were impressed by the project's maturity, even though we were applying for the Graduate level!
Regarding Microcks adopters list, TAG suggested adding the CNCF adopters categories, which have since been implemented and tracked in this issue.
TAG confirmed that the presentation meets the requirement to apply for Incubation, as stated in the issue: "Engage with the domain-specific TAG(s) to increase awareness through a presentation or completing a General Technical Review."
TAG provides insight/recommendation of the project in the context of the landscape
Microcks is designed and maintained to be vendor-neutral, fully aligned with the principles of the Cloud Native Computing Foundation (CNCF). Since its inception as a side project by Laurent Broudoux in 2015, Microcks has always been independent. It was later donated to the CNCF by its two core maintainers, ensuring openness and neutrality in governance, development, and community engagement from any vendors, including its main sponsor(s).
CNCF's vendor neutrality guidelines require projects to maintain impartiality in communication, hosting, architectural decisions, and governance. Microcks strictly adhere to these principles.
Communication:
Equal representation: Microcks maintains transparency by listing all third-party companies (website, adopters list...), without favoring any vendor.
CNCF-aligned website: The Microcks website follows CNCF guidelines to ensure neutrality.
Independent social media: Microcks' LinkedIn, X, BlueSky, Mastodon, YouTube, and other channels do not endorse any particular vendor.
Open community discussions: Microcks GitHub, Discord and Slack communication takes place in the public workspaces, ensuring openness and broad participation.
Hosting:
CNCF GitHub Enterprise: Microcks' source code is hosted under the CNCF GitHub organization to maintain transparency and accessibility.
Independent CI/CD: Continuous integration testing using GitHub Actions ensures a vendor-agnostic testing environment.
Public meeting records: We hold monthly Open Community Meetings for each region, which means we have bi-weekly meetings to try to be worldwide friendly with recordings publicly available on YouTube. We are using Linux Foundation-managed service (Zoom, meeting schedule and calendar...), see Joining Microcks Community Meetings: A Step-by-Step Guide.
Architectural Decisions:
Open source by design: Microcks is a fully open source project, ensuring its codebase remains accessible for anyone to use, modify, and contribute without vendor influence.
Protocol-agnostic: Microcks supports a wide range of API open specifications and protocols (OpenAPI, GraphQL, AsyncAPI, SOAP, gRPC, Postman collection, etc.) to embrace cloud native application diversity and avoid dependence on any single technology or provider.
Cloud native flexibility: Microcks is designed to work with any Kubernetes distribution or Container engines, whether on-premises or in the cloud, ensuring no ties to specific infrastructure providers.
Community-driven roadmap: The Microcks roadmap is curated based on input from GitHub, Discord and Slack discussions, adopters requests and feedback and real-world use cases. The roadmap status is always accessible via the GitHub project board.
Governance:
CNCF Incubation Path: As a CNCF project moving towards Incubation, Microcks follows CNCF's commitment to **open standards, interoperability, and vendor neutrality.
Open governance model: Contributions are encouraged from a diverse community of individuals and organizations, ensuring broad participation.
Clear contribution path: We strive to make contributing to the Microcks project as simple and transparent as possible.
By maintaining these vendor-neutral principles, Microcks ensures long-term sustainability, trust, and openness within the API-first and cloud native ecosystem.
Review and acknowledgement of expectations for Sandbox projects and requirements for moving forward through the CNCF Maturity levels.
Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisfies the Due Diligence Review criteria.
Additional documentation as appropriate for project type, e.g.: installation documentation, end user documentation, reference implementation and/or code samples.
You can explore our documentation, where we've added key sections, including tutorials, guides, reference materials, and explanations to support our adopters learning journey. Our documentation follows the Diátaxis methodology, and in 2024, we undertook a six-month complete refactoring to enhance its clarity and structure.
Additionally, we feature contributions and blog posts from adopters and contributors:
Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.
Suggested
Clear and discoverable project governance documentation.
Microcks' governance documentation is hosted in the .github repository alongside our global community files. Using GitHub Actions, this content is replicated and synchronized across all organization repositories.
Governance has continuously been iterated upon by the project as a result of their experience applying it, with the governance history demonstrating evolution of maturity alongside the project's maturity evolution.
Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).
Demonstrate usage of the maintainer lifecycle with outcomes, either through the addition or replacement of maintainers as project events have required.
Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.
Suggested
Contributor ladder with multiple roles for contributors.
The Microcks Governance file outlines the roles and responsibilities of different contributor types and details the path from contributor to maintainer.
Required
Clearly defined and discoverable process to submit issues or changes.
The Microcks Contributing file provides guidelines on reporting issues and contributing to the project.
Project must have, and document, at least one public communications channel for users and/or contributors.
Links to public communication channels are provided on the organization repo README and community repo README and all the sub-projects repos
List and document all project communication channels, including subprojects (mail list/slack/etc.). List any non-public communications channels and what their special purpose is.
For private communications between maintainers and handling sensitive online topics, we use Discord DM (Direct Message). In case of emergencies and only if maintainers are away from their keyboards, we use mobile phone numbers.
Up-to-date public meeting schedulers and/or integration with CNCF calendar.
Microcks hosts two monthly community meetings (documented here), tailored for different time zones. Here’s how to join and participate:
APAC-friendly Meeting: Second Thursday of each month
Time: 9–10 a.m. CET / 1–2 p.m. Bengaluru
America-friendly Meeting: Fourth Thursday of each month
Time: 6–7 p.m. CET / 1–2 p.m. EST / 9–10 a.m. PST
Documentation of how to contribute, with increasing detail as the project matures.
See, the Microcks Contributing file. This content is replicated and synchronized across all organization repositories using GitHub Actions.
Demonstrate contributor activity and recruitment.
Contributor Growth: 2024 saw significant contributors’ growth, demonstrating our community’s enthusiasm and commitment. According to DevStats, Microcks had 74 contributors in 2024. These include committers from 24 organizations such as Google, Red Hat, Catena Clearing, Vinted, Adeo, Bancolumbia, OPT New Caledonia and so on.
We follow a regular release cadence, see the main repo. All the releases are tracked in GitHub repositories. All sub-projects expose their own GitHub releases as well. All are automated using JReleaser or GoReleaser.
Document project goals and objectives that illustrate the project’s differentiation in the Cloud Native landscape as well as outlines how this project fulfills an outstanding need and/or solves a problem differently. This can also be satisfied by completing a General Technical Review.
See these publications to share documents, Microcks, vision, goals and objectives:
Document what the project does, and why it does it - including viable cloud native use cases. This can also be satisfied by completing a General Technical Review.
Adopters quotes: Ludovic Pourrat - API Architect | Platform Architect at Lombard Odier Group:
Microcks is a robust open source tool that has become an essential solution for Lombard Odier. It enables us to manage, maintain, and automate the lifecycle of our extensive API ecosystem efficiently. At the heart of our remarkable journey, Microcks has become a key asset that achieves the right balance between innovation and stability, empowering developers with fast iterations of their APIs.
Carol Gschwend - Expert Software Engineer at J.B. Hunt Transport Services, Inc:
The developers of the project mentioned above saved at least 7 months using Microcks. They were not only able to work concurrently but also captured the exact business requirements specified by the product owner in the form of example request/response pairs. These persistent mocks can now be utilized in sandbox environments if needed.
Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.
Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation. This can also be satisfied by completing a General Technical Review and capturing the output in the project's documentation.
Microcks architecture and software design are in the project documentation:
Microcks components are distributed as OCI container images for container runtimes such as Docker or Podman. The Microcks container images adhere to a versioning scheme where the x.y.z or x.y.z-fix-N (for critical fixes) tag denotes a stable release from a GitHub repo tag and is immutable. Additionally, there are mutable tags like latest and nightly that point to the most recent stable or potentially unstable build, respectively.
The project has fully automated the build and release process so all delivered components and their provenance attestations are signed using the GitHub Action provided identities (following the in-toto framework).
Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)
As a GitHub hosted project, we rely on the GitHub authentication mechanisms. All the maintainers and bots (GitHub Actions and Workflow) use two factor authentication and sign commits. The maintainers are responsible for regularly reviewing and updating the organization's membership enforcing 2FA and commit signature checks.
Document assignment of security response roles and how reports are handled.
To reinforce our commitment to this task and enhance our understanding, both Microcks maintainers have completed the Linux Foundation Training & Certification: Security Self-Assessments for Open Source Projects (LFEL1005).
Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.
Our current Open Source Security Foundation (OpenSSF) score for the main repository is 99% (View Score). However, the Microcks team is committed to improving this score to 100% and achieving the passing stage.
Why Not 100%? We currently have a temporary outstanding issue with Microcks UI-related dependencies that we are unable to upgrade, preventing us from reaching 100% compliance. This issue is specific to the Microcks UI and does not impact the core services of Microcks, which are typically used directly by applications relying on Microcks. We have initiated a brainstorming session and action plan with the community to address this. You can follow the discussion and progress here: GitHub Discussion #1458. This is a work in progress, and we aim to resolve it in the coming months.
We have also made significant efforts to enhance our overall security and compliance across all 19 repositories using CLOMonitor checks (View CLOMonitor Report). Currently, our overall CLOMonitor score is 98, rating Microcks at an "A" grade. This was a long process initiated in June 2024 (Issue #1201), reflecting our continued commitment to improving project security and best practices.
Microcks ranks Update project proposal process to move to GitHub #8 among 205 CNCF projects (including Incubating and Graduated projects!). Additionally, we hold the top position for the most repositories and checks among all CNCF projects.
Top 10 CNCF Projects by Repositories Checked via CLOMonitor:
Microcks – 19 repositories
OpenEBS – 10 repositories
Devfile & In-Toto – 9 repositories each
Argo – 7 repositories
etcd & gRPC – 6 repositories each
CloudEvents – 6 repositories (though not all require code checks)
Metal3-io – 5 repositories
Envoy – 5 repositories
Cilium, Fluentd, Prometheus, and Strimzi – 4 repositories each
Microcks remains dedicated to maintaining and improving security and compliance across our projects!
Tools we use to secure our supply chain:
Sonar Cloud,
FOSSA,
Cosign / Sigstore,
Clair / Docker Scout,
Syft
Ecosystem
Suggested
N/A
Required
Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)
Microcks has reviewed and understands the CNCF definition of an adopter. TAG suggested adding the CNCF adopters categories, which have since been implemented and tracked in this issue.
Used in appropriate capacity by at least 3 independent + indirect/direct adopters, (these are not required to be in the publicly documented list of adopters)
The project has provided the TOC with a list of 6 adopters who are willing to be interviewed by the TOC reviewer(s) using the Adopter Interview Questionnaire to confirm that the project is being utilized at the expected level.
TOC verification of adopters.
Refer to the Adoption portion of this document.
Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects.
Microcks welcomes the TOC Technical Advisory Groups - Restructuring (alias TAG Reboot), particularly the creation of the new Developer Experience TAG, recognizing the crucial role of developers in the cloud native ecosystem.
While Microcks is an API and microservices tooling “by developers, for developers,” it also serves as a bridge between all enterprise stakeholders, from business and product owners to developers connecting various API specifications and assets.
We are excited to contribute to this new TAG, supporting communities and enterprises in simplifying cloud native development, application lifecycle management, and modernization.
The text was updated successfully, but these errors were encountered:
The latest task has been completed:
"
The project has provided the TOC with a list of 6 adopters who are willing to be interviewed by the TOC reviewer(s) using the Adopter Interview Questionnaire to confirm that the project is being utilized at the expected level.
"
A 7th adopter willing to be interviewed by the TOC reviewer(s) has been provided. We are all set on this point and look forward to the go/no-go triage decision. Thank you.
Review Project Moving Level Evaluation
[x] I have reviewed the TOC's moving level readiness triage guide, ensured the criteria for my project are met before opening this issue, and understand that unmet criteria will result in the project's application being closed.
Microcks Incubation Application
v1.6
This template provides the project with a framework to inform the TOC of their conformance to the Incubation Level Criteria.
Project Repo(s): https://github.com/microcks/microcks
Project Site: https://microcks.io/
Sub-Projects: https://github.com/orgs/microcks/repositories
Communication: Discord (preferred) or #microcks channel in CNCF Slack workspace (alternate)
Project points of contacts:
Incubation Criteria Summary for $PROJECT
Application Level Assertion
Adoption Assertion
The project has been adopted by the following organizations in a testing and integration or production capacity:
Application Process Principles
Suggested
N/A
Required
Engage with the domain specific TAG(s) to increase awareness through a presentation or completing a General Technical Review.
A presentation to the TAG App Delivery was conducted on February 19, 2025 (19-02-2025), during the TAG General Meeting. The recording is available on the TAG YouTube channel here.
This 3rd presentation (2025-02-19) - TAG App Delivery - Microcks update focused more on project information and community metrics than technical details.
TAG members had no objections or specific recommendations, see: CNCF TAG App Delivery Meeting Notes; they were impressed by the project's maturity, even though we were applying for the Graduate level!
Regarding Microcks adopters list, TAG suggested adding the CNCF adopters categories, which have since been implemented and tracked in this issue.
TAG confirmed that the presentation meets the requirement to apply for Incubation, as stated in the issue: "Engage with the domain-specific TAG(s) to increase awareness through a presentation or completing a General Technical Review."
TAG provides insight/recommendation of the project in the context of the landscape
All project metadata and resources are vendor-neutral.
Microcks is designed and maintained to be vendor-neutral, fully aligned with the principles of the Cloud Native Computing Foundation (CNCF). Since its inception as a side project by Laurent Broudoux in 2015, Microcks has always been independent. It was later donated to the CNCF by its two core maintainers, ensuring openness and neutrality in governance, development, and community engagement from any vendors, including its main sponsor(s).
CNCF's vendor neutrality guidelines require projects to maintain impartiality in communication, hosting, architectural decisions, and governance. Microcks strictly adhere to these principles.
Communication:
Equal representation: Microcks maintains transparency by listing all third-party companies (website, adopters list...), without favoring any vendor.
CNCF-aligned website: The Microcks website follows CNCF guidelines to ensure neutrality.
Independent social media: Microcks' LinkedIn, X, BlueSky, Mastodon, YouTube, and other channels do not endorse any particular vendor.
Open community discussions: Microcks GitHub, Discord and Slack communication takes place in the public workspaces, ensuring openness and broad participation.
Hosting:
CNCF GitHub Enterprise: Microcks' source code is hosted under the CNCF GitHub organization to maintain transparency and accessibility.
Independent CI/CD: Continuous integration testing using GitHub Actions ensures a vendor-agnostic testing environment.
Public meeting records: We hold monthly Open Community Meetings for each region, which means we have bi-weekly meetings to try to be worldwide friendly with recordings publicly available on YouTube. We are using Linux Foundation-managed service (Zoom, meeting schedule and calendar...), see Joining Microcks Community Meetings: A Step-by-Step Guide.
Architectural Decisions:
Open source by design: Microcks is a fully open source project, ensuring its codebase remains accessible for anyone to use, modify, and contribute without vendor influence.
Protocol-agnostic: Microcks supports a wide range of API open specifications and protocols (OpenAPI, GraphQL, AsyncAPI, SOAP, gRPC, Postman collection, etc.) to embrace cloud native application diversity and avoid dependence on any single technology or provider.
Cloud native flexibility: Microcks is designed to work with any Kubernetes distribution or Container engines, whether on-premises or in the cloud, ensuring no ties to specific infrastructure providers.
Community-driven roadmap: The Microcks roadmap is curated based on input from GitHub, Discord and Slack discussions, adopters requests and feedback and real-world use cases. The roadmap status is always accessible via the GitHub project board.
Governance:
CNCF Incubation Path: As a CNCF project moving towards Incubation, Microcks follows CNCF's commitment to **open standards, interoperability, and vendor neutrality.
Open governance model: Contributions are encouraged from a diverse community of individuals and organizations, ensuring broad participation.
Clear contribution path: We strive to make contributing to the Microcks project as simple and transparent as possible.
By maintaining these vendor-neutral principles, Microcks ensures long-term sustainability, trust, and openness within the API-first and cloud native ecosystem.
Review and acknowledgement of expectations for Sandbox projects and requirements for moving forward through the CNCF Maturity levels.
The requirements for the project's application and Sandbox onboarding were met during the process, with issue [SANDBOX PROJECT ONBOARDING] Microcks sandbox#197 addressing the necessary steps.
Due Diligence Review.
Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisfies the Due Diligence Review criteria.
Additional documentation as appropriate for project type, e.g.: installation documentation, end user documentation, reference implementation and/or code samples.
You can explore our documentation, where we've added key sections, including tutorials, guides, reference materials, and explanations to support our adopters learning journey. Our documentation follows the Diátaxis methodology, and in 2024, we undertook a six-month complete refactoring to enhance its clarity and structure.
Additionally, we feature contributions and blog posts from adopters and contributors:
As well as code demos:
And in-depth blog posts covering both technical and high-level topics:
Governance and Maintainers
Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.
Suggested
Clear and discoverable project governance documentation.
Microcks' governance documentation is hosted in the
.github
repository alongside our global community files. Using GitHub Actions, this content is replicated and synchronized across all organization repositories.Governance has continuously been iterated upon by the project as a result of their experience applying it, with the governance history demonstrating evolution of maturity alongside the project's maturity evolution.
Microcks' maintainers prioritize inclusivity and simplicity. While our governance model has evolved over time, we have intentionally kept it straightforward, avoiding complex hierarchies, as we remain a relatively small team. See a few examples: Update and sync MAINTAINERS.md microcks/.github#18, Refresh and Update Community Files microcks/.github#45
Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.
Documented in Microcks Governance file.
Governance clearly documents vendor-neutrality of project direction.
Documented in Microcks Governance:
Document how the project makes decisions on leadership, contribution acceptance, requests to the CNCF, and changes to governance or project goals.
Documented in Microcks Governance file.
Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).
Documented in Microcks Governance file.
Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status).
Documented in Microcks Governance file.
Demonstrate usage of the maintainer lifecycle with outcomes, either through the addition or replacement of maintainers as project events have required.
See, Update and sync MAINTAINERS.md microcks/.github#18, Refresh and Update Community Files microcks/.github#45
If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.
Documented in Microcks Governance file.
Required
Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.
Documented in the Maintainers and Code Owners list.
A number of active maintainers which is appropriate to the size and scope of the project.
There are 2 maintainers and 3 Code Owners (alias Domain Maintainers), as documented in the Maintainers and Code Owners list.
Code and Doc ownership in Github and elsewhere matches documented governance roles.
All the repositories have
CODEOWNERS
files.Document adoption of the CNCF Code of Conduct
See, Microcks Code of Conduct file. This content is replicated and synchronized across all organization repositories using GitHub Actions.
CNCF Code of Conduct is cross-linked from other governance documents.
Documented in our Code of Conduct file.
All subprojects, if any, are listed.
Contributors and Community
Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.
Suggested
Contributor ladder with multiple roles for contributors.
The Microcks Governance file outlines the roles and responsibilities of different contributor types and details the path from contributor to maintainer.
Required
Clearly defined and discoverable process to submit issues or changes.
The Microcks Contributing file provides guidelines on reporting issues and contributing to the project.
Project must have, and document, at least one public communications channel for users and/or contributors.
Links to public communication channels are provided on the organization repo README and community repo README and all the sub-projects repos
Also featured on the Microcks website: https://microcks.io/community/
List and document all project communication channels, including subprojects (mail list/slack/etc.). List any non-public communications channels and what their special purpose is.
For private communications between maintainers and handling sensitive online topics, we use Discord DM (Direct Message). In case of emergencies and only if maintainers are away from their keyboards, we use mobile phone numbers.
Up-to-date public meeting schedulers and/or integration with CNCF calendar.
Microcks hosts two monthly community meetings (documented here), tailored for different time zones. Here’s how to join and participate:
APAC-friendly Meeting: Second Thursday of each month
Time: 9–10 a.m. CET / 1–2 p.m. Bengaluru
America-friendly Meeting: Fourth Thursday of each month
Time: 6–7 p.m. CET / 1–2 p.m. EST / 9–10 a.m. PST
The event is listed on the CNCF calendar: https://www.cncf.io/calendar and https://zoom-lfx.platform.linuxfoundation.org/meetings/microcks?view=month
We have also created a guide titled "Joining Microcks Community Meetings" to help newcomers join us with less friction.
Documentation of how to contribute, with increasing detail as the project matures.
See, the Microcks Contributing file. This content is replicated and synchronized across all organization repositories using GitHub Actions.
Demonstrate contributor activity and recruitment.
Contributor Growth: 2024 saw significant contributors’ growth, demonstrating our community’s enthusiasm and commitment. According to DevStats, Microcks had 74 contributors in 2024. These include committers from 24 organizations such as Google, Red Hat, Catena Clearing, Vinted, Adeo, Bancolumbia, OPT New Caledonia and so on.
Activity can be seen through LFX Insights, DevStats, GitHub.
For recruitment, we actively promote our activities and share our metrics: A Thriving year in the CNCF Sandbox and Its Transformative Impacts and Recap of an Amazing 2024, and ready to go for 2025!. Additionally, we are participating in the LFX Mentorship Program in 2025 with 7 projects and 7 mentees.
Engineering Principles
Suggested
Roadmap change process is documented.
Documented in Microcks Roadmap.
History of regular, quality releases.
We follow a regular release cadence, see the main repo. All the releases are tracked in GitHub repositories. All sub-projects expose their own GitHub releases as well. All are automated using JReleaser or GoReleaser.
See the shoutout from Java champion, Andres Almiray on LinkedIn:
We also write a blog post for each new release of the core project:
Required
Document project goals and objectives that illustrate the project’s differentiation in the Cloud Native landscape as well as outlines how this project fulfills an outstanding need and/or solves a problem differently. This can also be satisfied by completing a General Technical Review.
See these publications to share documents, Microcks, vision, goals and objectives:
Document what the project does, and why it does it - including viable cloud native use cases. This can also be satisfied by completing a General Technical Review.
See these publications to share and documents:
https://microcks.io/blog/why-microcks/
https://microcks.io/documentation/overview/what-is-microcks/
https://microcks.io/documentation/overview/main-concepts/
Adopters use cases:
Revolutionizing API Strategy: Lombard Odier's Success Story with Microcks
CNAM Partners with Microcks for Automated SOAP Service Mocking
J.B. Hunt: Mock It till You Make It with Microcks
Adopters quotes:
Ludovic Pourrat - API Architect | Platform Architect at Lombard Odier Group:
Microcks is a robust open source tool that has become an essential solution for Lombard Odier. It enables us to manage, maintain, and automate the lifecycle of our extensive API ecosystem efficiently. At the heart of our remarkable journey, Microcks has become a key asset that achieves the right balance between innovation and stability, empowering developers with fast iterations of their APIs.
Carol Gschwend - Expert Software Engineer at J.B. Hunt Transport Services, Inc:
The developers of the project mentioned above saved at least 7 months using Microcks. They were not only able to work concurrently but also captured the exact business requirements specified by the product owner in the form of example request/response pairs. These persistent mocks can now be utilized in sandbox environments if needed.
Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.
See, Microcks Roadmap
Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation. This can also be satisfied by completing a General Technical Review and capturing the output in the project's documentation.
Microcks architecture and software design are in the project documentation:
Document the project's release process.
Microcks components are distributed as OCI container images for container runtimes such as Docker or Podman. The Microcks container images adhere to a versioning scheme where the x.y.z or x.y.z-fix-N (for critical fixes) tag denotes a stable release from a GitHub repo tag and is immutable. Additionally, there are mutable tags like
latest
andnightly
that point to the most recent stable or potentially unstable build, respectively.The project has fully automated the build and release process so all delivered components and their provenance attestations are signed using the GitHub Action provided identities (following the in-toto framework).
For a full description of Microcks container images, software supply chain security, including SBOM and provenance attestations, see: https://microcks.io/documentation/references/container-images/
Security
Note: this section may be augmented by a joint-assessment performed by TAG Security.
Suggested
N/A
Required
Clearly defined and discoverable process to report security issues.
Documented in the Microcks Security file.
Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)
As a GitHub hosted project, we rely on the GitHub authentication mechanisms. All the maintainers and bots (GitHub Actions and Workflow) use two factor authentication and sign commits. The maintainers are responsible for regularly reviewing and updating the organization's membership enforcing 2FA and commit signature checks.
Document assignment of security response roles and how reports are handled.
Documented in the Microcks Security file.
Document Security Self-Assessment.
Reviewed and merged: See, the Microcks Security Self-Assessment PR. Microcks document is now online.
To reinforce our commitment to this task and enhance our understanding, both Microcks maintainers have completed the Linux Foundation Training & Certification: Security Self-Assessments for Open Source Projects (LFEL1005).
See our certifications here:
Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.
Our current Open Source Security Foundation (OpenSSF) score for the main repository is 99% (View Score). However, the Microcks team is committed to improving this score to 100% and achieving the passing stage.
Why Not 100%? We currently have a temporary outstanding issue with Microcks UI-related dependencies that we are unable to upgrade, preventing us from reaching 100% compliance. This issue is specific to the Microcks UI and does not impact the core services of Microcks, which are typically used directly by applications relying on Microcks. We have initiated a brainstorming session and action plan with the community to address this. You can follow the discussion and progress here: GitHub Discussion #1458. This is a work in progress, and we aim to resolve it in the coming months.
We have also made significant efforts to enhance our overall security and compliance across all 19 repositories using CLOMonitor checks (View CLOMonitor Report). Currently, our overall CLOMonitor score is 98, rating Microcks at an "A" grade. This was a long process initiated in June 2024 (Issue #1201), reflecting our continued commitment to improving project security and best practices.
Microcks ranks Update project proposal process to move to GitHub #8 among 205 CNCF projects (including Incubating and Graduated projects!). Additionally, we hold the top position for the most repositories and checks among all CNCF projects.
Top 10 CNCF Projects by Repositories Checked via CLOMonitor:
Microcks remains dedicated to maintaining and improving security and compliance across our projects!
Tools we use to secure our supply chain:
Ecosystem
Suggested
N/A
Required
Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)
See Microcks public adopters list: ADOPTERS.md
Microcks has reviewed and understands the CNCF definition of an adopter. TAG suggested adding the CNCF adopters categories, which have since been implemented and tracked in this issue.
Used in appropriate capacity by at least 3 independent + indirect/direct adopters, (these are not required to be in the publicly documented list of adopters)
The project has provided the TOC with a list of 6 adopters who are willing to be interviewed by the TOC reviewer(s) using the Adopter Interview Questionnaire to confirm that the project is being utilized at the expected level.
TOC verification of adopters.
Refer to the Adoption portion of this document.
Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects.
See, TAG App Delivery - Microcks update deck for the big picture.
More details:
Additional Information
Microcks welcomes the TOC Technical Advisory Groups - Restructuring (alias TAG Reboot), particularly the creation of the new Developer Experience TAG, recognizing the crucial role of developers in the cloud native ecosystem.
While Microcks is an API and microservices tooling “by developers, for developers,” it also serves as a bridge between all enterprise stakeholders, from business and product owners to developers connecting various API specifications and assets.
We are excited to contribute to this new TAG, supporting communities and enterprises in simplifying cloud native development, application lifecycle management, and modernization.
The text was updated successfully, but these errors were encountered: