https://sdlc.learnable.team/Recent content in Introduction on Learnable Secure SDLCHugoen-ushttps://sdlc.learnable.team/process/ssdlc/build/binary_provenance/Mon, 01 Jan 0001 00:00:00 +0000https://sdlc.learnable.team/process/ssdlc/build/binary_provenance/Artifact Binary Provenance # TLDR: Every software running production has known provenance Rationale: High security environment require a tamper-proof identity scheme. The use of Content Addressable Storage mechanisms ensures that if software changes it will have a different identity. Background # To define software identity, you use the cryptographic hash of the software itself. We use the SHA256 digest of the sofware binary. This means that if a single byte in the software changes it will have a different identity.https://sdlc.learnable.team/process/ssdlc/build/versioncontrol/Mon, 01 Jan 0001 00:00:00 +0000https://sdlc.learnable.team/process/ssdlc/build/versioncontrol/Version Control # TLDR: Every change to the source is tracked in a version control system Rationale: Version control allows us to track and manage changes to our software code. As a traceability system, it provides a means to understand how our software changes, who changes it, and why it was changed. Background # We use git to manage versioning for software development source code. For repository hosting and user management we use github.https://sdlc.learnable.team/process/ssdlc/runtime/change_records/Mon, 01 Jan 0001 00:00:00 +0000https://sdlc.learnable.team/process/ssdlc/runtime/change_records/Change Records # TLDR: All systems and services maintain a record of changes Rationale: To meet our change management requirements, all changes to production systems are recorded permanently Background # The deployment steps in our pipelines automatically log all deployments, and we can also control that we only deploy software that is approved in the a compliance system of record audit trail.https://sdlc.learnable.team/process/ssdlc/process/code_review/Mon, 01 Jan 0001 00:00:00 +0000https://sdlc.learnable.team/process/ssdlc/process/code_review/Code Review # TLDR: Code review is performed on all software changes Rationale: Peer review is an essential mitigation against insider threats, as well as a means of improving knowledege sharing and quality. Background # We use pull requests to document code reviews. The pull request description should contain key information of the change, as well as any relevant information. At a minimum, code reviews should be performed by someone capable of understanding the change and it’s associated risks.https://sdlc.learnable.team/process/exception_register/Mon, 01 Jan 0001 00:00:00 +0000https://sdlc.learnable.team/process/exception_register/Exception Register # Where a team cannot meet a control defined in this process, the deviation is recorded as an exception, along with the rationale for it. Recording an exception is always preferable to quietly diverging from the process. The current list of exceptions is maintained in the team wiki, which is the authoritative record. Anyone with Learnable access can find it there. No list and no link appear on this page.https://sdlc.learnable.team/process/risk_register/Mon, 01 Jan 0001 00:00:00 +0000https://sdlc.learnable.team/process/risk_register/Risk Register # The risk register is the list of risks this process exists to control, together with their severity, ownership, and current status. It is maintained in Linear, which is the authoritative record. Anyone with Learnable access can find it there. No list and no link appear on this page. This site is published publicly, whereas the register itself is internal. Each control described in this process carries a rationale explaining the risk it addresses, so the reasoning behind a control stays with the control itself.https://sdlc.learnable.team/process/training/Mon, 01 Jan 0001 00:00:00 +0000https://sdlc.learnable.team/process/training/Training # The team will annually go through the OWASP top 10 security risks and discuss them. The date of the session and its participants will be recorded in a compliance system of record. For new employees the OWASP top 10 will be done together with one of the other team members.https://sdlc.learnable.team/background/why/Mon, 01 Jan 0001 00:00:00 +0000https://sdlc.learnable.team/background/why/Who needs to define a software process? # Regulated software companies like banks, fintechs, healthcare providers, medical device manufacturers, etc. need to comply with government legislation and/or industry standards (IEC 62304, ISO26262, NIST, FDA, etc.) before they can take products to market and sell to customers. Many non-regulated companies also choose to opt-in to standards like SOC2 and ISO27001 to win the confidence of their customers. To achieve compliance with any of these regulations and standards involves defining a software delivery process, implementing it, and then proving that the process is being followed.https://sdlc.learnable.team/process/ssdlc/build/toolchain/Mon, 01 Jan 0001 00:00:00 +0000https://sdlc.learnable.team/process/ssdlc/build/toolchain/Defined Toolchain # TLDR: Build environments must be defined securely and auditable Rationale: A secure build environment is the foundation for a mitigating software supply chain attacks. Build environments defined as code protect against interference that can happen in the build and distribution processes. Background # Builds that are scripted, ran in an ephemeral and controlled build environment are more resilient against supply chain attacks. If at all possible, we recommend teams use immutable docker images to define the build environment.https://sdlc.learnable.team/process/ssdlc/build/dependencies/Mon, 01 Jan 0001 00:00:00 +0000https://sdlc.learnable.team/process/ssdlc/build/dependencies/Dependency Management # TLDR: Every dependency is defined securely, managed, and auditable Rationale: Inputs to the build process can introduce security and quality issues, and as such must be defined, controlled, and transparent as part of the software development lifecycle. Background # Key points: You must have control over what dependencies are packaged in your software All dependencies must comply with licensing requirements Must only use software with licences agreed by Learnable Dependencies can include docker base images, 3rd-party libraries, and other source code.https://sdlc.learnable.team/process/ssdlc/runtime/deployment_controls/Mon, 01 Jan 0001 00:00:00 +0000https://sdlc.learnable.team/process/ssdlc/runtime/deployment_controls/Deployment Controls # TLDR: Deployments controls are enforced in the pipeline and environments Rationale: Ensuring only compliant, approved software deployments are made to production Background # We use deployment controls to automatically ensure we only deploy software that has gone through our Software Development Lifecycle. This can be implemented as a gate in the pipeline, or as an admission control in the environment (ideally both).https://sdlc.learnable.team/process/ssdlc/process/quality/Mon, 01 Jan 0001 00:00:00 +0000https://sdlc.learnable.team/process/ssdlc/process/quality/Quality Assurance # TLDR: Functionality of software is assured prior to production Rationale: Every change has the potential to introduce regressions in functionality. By testing our software prior to deployment we manage the risk of production issues. Background # If it matters that a software system functions according to expectations, we must test and qualify our software prior to production. The level of testing and qualification should correspond to the risk appetite for a particular system.https://sdlc.learnable.team/background/devops/Mon, 01 Jan 0001 00:00:00 +0000https://sdlc.learnable.team/background/devops/DevOps Compliance Culture # TLDR: DevOps teams who understand and conform to process with automation support outperform teams with external approvals and compliance managers. The way we build and deliver software has changed significantly over the years. In the past, we would build systems on large, custom managed hardware. Organizations were siloed by specialty, with different departments for analysis, development, quality assurance, and operations. Software was delivered in releases, once a year, or once a quarter even.https://sdlc.learnable.team/process/ssdlc/runtime/secrets_managment/Mon, 01 Jan 0001 00:00:00 +0000https://sdlc.learnable.team/process/ssdlc/runtime/secrets_managment/Secrets Management # TLDR: Build and runtime secrets are stored securely and documented appropriately Rationale: Leaked secrets such as api keys, cryptography keys, identity tokens are a common attack scenario. Background # Secrets must be stored in a secure way, and a documented in a central place. Cryptographic failures are the second highest risk in the OWASP top ten so rigor and process is essential.https://sdlc.learnable.team/process/ssdlc/process/security/Mon, 01 Jan 0001 00:00:00 +0000https://sdlc.learnable.team/process/ssdlc/process/security/Security Vulnerability Scanning # TLDR: Software is scanned for security vulnerabilities prior to deployment Rationale: Many common security vulnerabilities can be detected with automated tools. By implementing tools for dependency scanning, SAST, and DAST in the pipeline we can reduce the attack surface of our software Background # Vulnerability scanning is the automated process of proactively identifying software vulnerabilities in software. Many common security attacks such as vulnerable components and insecure coding techniques can be prevented by integrating these tools in your devops, and acting in a timely manner on issues found.https://sdlc.learnable.team/process/ssdlc/process/deployment_approvals/Mon, 01 Jan 0001 00:00:00 +0000https://sdlc.learnable.team/process/ssdlc/process/deployment_approvals/Deployment Approvals # TLDR: Deployments are approved Rationale: To meet segregation of duties requirements, all deploymnents to production are approved by someone other than the person making the change Background # Segregations of duties is a common requirement in regulated or high security development environment. Put plainly, it means that a developer cannot deploy their own changes without approval from someone who both: Understands what is changing Accepts the risk of the change Deployment approval controls form a key role in the secure software development lifecycle.https://sdlc.learnable.team/process/ssdlc/runtime/service_ownership/Mon, 01 Jan 0001 00:00:00 +0000https://sdlc.learnable.team/process/ssdlc/runtime/service_ownership/Service ownership # TLDR: All services running in our environments have registered ownership Rationale: In a diverse software landscape it is essential everyone knows who is responsible for maintaince and support Background # In any governance system, risks are managed by controls. But humans are ultimately responsible.In this context there are many reasons to keep a register of service ownership in diverse software landscapes: Knowlege: Who knows how this is supposed to work?https://sdlc.learnable.team/process/ssdlc/runtime/workload_monitoring/Mon, 01 Jan 0001 00:00:00 +0000https://sdlc.learnable.team/process/ssdlc/runtime/workload_monitoring/Workload Monitoring # TLDR: Workloads are monitored to alert if any system is incompliant Rationale: Real-time closed-loop compliance monitoring is a constant vigil against threats Background # Ensuring that risks are controlled in the value stream is the first level of software process compliance. Beyond this, it is important to have a monitoring process in place to ensure that unknown or incompliant workloads are identified in production.