Ideation: OSS Architecture #61
Replies: 5 comments 1 reply
-
|
Category: Developer Experience - Onboarding with Codespaces Use case: speed up onboarding (similar to dev containers) in a cloud environment for optimal onboarding experience for both hackathon participants and student mentorship programs Context: We currently use the contributors guide for people to set up local environments in Mac, Linux, and Windows. It can sometimes create barriers for both students as well as those who would like to start contributing immediately. Mac users get the following error: @JamesMGreene has started the following issue to implement within backend: |
Beta Was this translation helpful? Give feedback.
-
|
Setting up CI in frontend Use Case: this will allow us to create tests for frontend instead of just backend |
Beta Was this translation helpful? Give feedback.
-
|
Category: Operations - Production Environments for Staging and Production Use case: have a different environment for hackathon and one that advocacy groups continue to use https://github.com/ProgramEquity/amplify-front-end/issues/80 |
Beta Was this translation helpful? Give feedback.
-
|
Category: AppSec - Security Policy |
Beta Was this translation helpful? Give feedback.
-
|
Hi, I have looked the workflows in the repository from security perspective. Good practices are in place, like permissions and hash pinning. No injections or |
Beta Was this translation helpful? Give feedback.
-
|
Dev Experience: Adding bugs to your workflows |
Beta Was this translation helpful? Give feedback.
-
Challenge
To echo the larger challenge of scaling this project within this hackathon - we focus on creating a robust OSS DevSecOps workflow and infrastructure.
Priorities
You might find this skillset track interesting if you hold any of the following titles:
Problem
More than 80% of the world’s software is built on open source. Log4J and Solorigates tested organizations across the world and how robust their infrastructure was when it came to operations, discovery, and remediation.
Maintainers navigate a very different world. Resources across tools, people, and time are afforded differently so we take on the lens of MGV when trying to adapt DevSecOps thats accessible in the projects that fuel our development heartbeats - open source.
This is an exploration of the accessibility of securing open source as discussed at the Open Summit at the White House earlier this year.
Goal
We plan to use Minimum Viable Governance framework so that security across user policies, infrastructure, appsec, app structure, data, and open source collaboration can scale seamlessly with the least amount of overhead.
MVG provides a two-tier structure for a set of open source projects. At the top level (called an “organization” on GitHub), there is a technical steering committee to make decisions about the overall direction and coordination between all the organization's projects. Underneath that top level are the individual projects, with lightweight, consensus-based governance.
Pillars of MVG:
Decision Making. MVG defaults to a consensus-based decision making process at the organization level. Consensus does not mean no objection - it means loose agreement by the stakeholders based on their dominant view, and taking outstanding objections into consideration. This is the approach that built the net. In our experience, striving for consensus reduces friction and reduces hostile project forks. At the organization/steering committee level, decisions that can’t be made by consensus fall back to majority vote. Individual repositories are consensus-only: if a decision can’t be made by consensus, it’s appealed to the steering committee.
Minimal Viable Risk Management: This is Appsec, zero trust policy, and protected workflows. Policies within administrative workflows which limit key decision making to OSS maintainers (steering comittee).
Functional Specifications
Amplify App
OSS Architecture:
How to get started
Review and pick a thread
Understand the context of the architecture
Pick an issue linked to discussion
Scope the problem you're hoping to add or seek input around
Submitting an issue:
Don't see a problem discussed? Discuss within your pod and skillset team to see if it worth submitting an issue. Use this template when submitting the issue
Table of Contents
App Structure:
We are going from a Single Page App Structure
To a CRUD App Structure
OSS Architecture:
OSS Architecture refers to all of the tools, workflows, and developer contribution pathways we're condensing under the DevSecOps model that works for open source - GitHub flows within an MVG framework.
Developer Experience
AppSec:
Background:
AppSec tools like SAST (Static Application Security Testing), DAST (Dynamic Application Security Testing), and others that address issues in proprietary software have become staples of the developer’s security toolbox. In addition, an AppSec strategy also needs to detect open source components with known vulnerabilities, and that’s where SCA (Software Composition Analysis) tools play an important role. Both SAST and SCA tools address vulnerabilities management. Each one operates differently, covers a different set of vulnerabilities, and even integrates into different stages of the software development lifecycle (SDLC).
Secure Workflows minimize risk across supply chain
Operations:
Operations refers to administrative practices for staging and monitoring production as well as policies and permissions.
Stack Best Practices
Beta Was this translation helpful? Give feedback.
All reactions