- Introduction
- Vulnerabilities
2.1 Supported Versions
2.2 Vulnerability Report
2.3 Security Disclosure - Security requrements
- Security Software life cycle processes
- Reproducible build
This document describes the sequence of actions when the vulnerability is founded, the product version that fixes them, security requirements, as well as the required process of developing a secure code.
To view the Items 3 & 4, you need to install a
plantumlextension for your browser.
We are releasing patches to eliminate vulnerabilities, you can see below:
| Version | Supported by | Edge-Orchestration | 3-rd party component |
|---|---|---|---|
| 1.0.0 | N/A | ||
| 1.1.0 | Fixed | CVE-2020-15257, CVE-2021-32760, CVE-2021-41103 | |
| 1.1.1 | Fixed | CVE-2021-41190 | |
| 1.1.4 | Fixed | CVE-2006-4624 | |
| 1.1.6 | Fixed | CVE-2006-4624 | |
| 1.1.8 | Fixed | CWE-843 | |
| 1.1.9 | Fixed | CVE-2022-23648 | |
| 1.1.11 | Fixed | CVE-2021-3121 | |
| 1.1.14 | Fixed | CVE-2022-28948, CVE-2021-41092, CVE-2022-31030 | |
| 1.2.1 | Fixed | CVE-2022-23471, CVE-2023-25153, CVE-2023025173 | |
| CVE-2023-28840, CVE-2023-28841, CVE-2023-28842 |
The Edge-Orchestration team assigns the highest priority to all security bugs in Edge-Orchestration project. We appreciate your efforts and responsible disclosure of information to eliminate vulnerabilities.
Please report security bugs by emailing the Security Issue Review (SIR) team at: homeedge-security-issues@lists.lfedge.org marked "SECURITY". Our team will confirm your request and within 1 week will try to prepare recommendations for elimination. Our team will keep you updated on the progress towards the fix until the full announcement of the patch release. During this process, the edge-orchestration team may request additional information or guidance.
When a security group receives a security error report as previously mentioned, it is assigned the highest priority and the person in charge. This person will coordinate the patch and release process, including the following steps:
- Confirm the problem and identify the affected versions.
- Check the code to find any similar problems.
- Prepare fixes for all releases still in maintenance. These fixes will released as quickly as possible.
We suggest the following format when disclosing vulnerabilities:
- Your name and email.
- Include scope of vulnerability. Let us know who could use this exploit.
- Document steps to identify the vulnerability. It is important that we can reproduce your findings.
- How to exploit vulnerability, give us an attack scenario.
@startuml
left to right direction
usecase "Security requirements" #palegreen;line:black
usecase Confidentiality as Co #lightblue;line:black
usecase Integrity as In #lightblue;line:black
usecase Availability as Av #lightblue;line:black
usecase "Access control" as Ac #lightblue;line:black
usecase Identification #lightblue;line:black
usecase Authentication #lightblue;line:black
usecase Authorization #lightblue;line:black
usecase Non #lightblue;line:black as "Non-public data
is kept confidential"
usecase "User privacy maintaned" #lightblue;line:black
usecase "All data is confidential" #lightblue;line:black
usecase "HTTPS: data in motion" #lightblue;line:black
usecase "Authorization via GITHUB" #lightblue;line:black
usecase Dtm #lightblue;line:black as "Data modification
requires authorization"
usecase "Multiple backups" #lightblue;line:black
usecase "Rerstore after DDoS" #lightblue;line:black
(Security requirements) <-- (Co) #line:black;line.bold
(Security requirements) <-- (In) #line:black;line.bold
(Security requirements) <-- (Av) #line:black;line.bold
(Security requirements) <-- (Ac) #line:black;line.bold
(Ac) <-- (Identification) #line:black
(Ac) <-- (Authentication) #line:black
(Ac) <-- (Authorization) #line:black
(Co) <-- (User privacy maintaned) #line:black
(Co) <-- (Non) #line:black
(Co) <-- (All data is confidential) #line:black
(Co) <-- (HTTPS: data in motion) #line:black
(In) <-- (HTTPS: data in motion) #line:black
(In) <-- (Authorization via GITHUB) #line:black
(In) <-- (Dtm) #line:black
(Av) <-- (Multiple backups) #line:black
(Av) <-- (Rerstore after DDoS) #line:black
@enduml@startuml
left to right direction
usecase SSLCP #palegreen;line:black as "Security Software
life cycle processes"
usecase "Certification & Controls" as CC #lightblue;line:black
usecase CBPB #lightblue;line:black as "CII Best
Practices badge"
usecase "OpenSSF Score Card" as OSSFSC #lightblue;line:black
usecase "Security in maintenance" as SM #lightblue;line:black
usecase ADPV #lightblue;line:black as "Auto-detect publicy
vulnerabilities"
usecase "Rapid update" as RU #lightblue;line:black
usecase KDKDSS #lightblue;line:black as "Key developers know how to
develop secure software"
usecase "Infrastructure management" as IM #lightblue;line:black
usecase DTEPA #lightblue;line:black as "Development & test
environments protected
from attack"
usecase CIATEP #lightblue;line:black as "CI automated test
environment does not have
protected data"
usecase SIV #lightblue;line:black as "Security in integration
& verification"
usecase "Style checking tools" as SCT #lightblue;line:black
usecase SCWA #lightblue;line:black as "Source code
weakness analyzer"
usecase FLOSS #lightblue;line:black
usecase "Negative Testing" as NT #lightblue;line:black
usecase UTC #lightblue;line:black as "Unit Test
coverage >75%"
usecase "Security in design" as SD #lightblue;line:black
usecase "Simple design" as SID #lightblue;line:black
usecase "Memory-safe languages" as MSL #lightblue;line:black
usecase SDISS #lightblue;line:black as "Secure disign
includes S&S"
(SSLCP) <-- (CC) #line:black;line.bold
(SSLCP) <-- (SM) #line:black;line.bold
(SSLCP) <-- (KDKDSS) #line:black;line.bold
(SSLCP) <-- (SIV) #line:black;line.bold
(SSLCP) <-- (IM) #line:black;line.bold
(SSLCP) <-- (SD) #line:black;line.bold
(CC) <-- (CBPB) #line:black
(CC) <-- (OSSFSC) #line:black
(SM) <-- (ADPV) #line:black
(SM) <-- (RU) #line:black
(IM) <-- (DTEPA) #line:black
(IM) <-- (CIATEP) #line:black
(SIV) <-- (SCT) #line:black
(SIV) <-- (SCWA) #line:black
(SIV) <-- (FLOSS) #line:black
(SIV) <-- (NT) #line:black
(SIV) <-- (UTC) #line:black
(SD) <-- (SID) #line:black
(SD) <-- (MSL) #line:black
(SD) <-- (SDISS) #line:black
@endumlReproducible builds, also known as deterministic compilation, is a process of compiling software which ensures the resulting binary code can be reproduced. Source code compiled using deterministic compilation will always output the same binary from Wikipedia & other useful information.
To create reproducible build, should do the following steps:
- Download source code (Ex.
git clone https://github.com/lf-edge/edge-home-orchestration-go.git). - Checkout to the commit corresponding to the tag version (Ex.
git checkout <your_commit>). - Install all packages, software and environment that was used to create this version (See documentation).
- Execute build command (How to build).
- Compare the resulting executable
edge-orchestrationfile with the original (Ex.diff bin/edge-orchestration <origin_edge-orchestration_file>).