It seems to be in the scope and charter of the DA to be kept appraised of any significant changes or projects that concern security of the Mojaloop code or environment. So the DA should request a briefing on the current security project being undertaken by Cylab. This seems to be very much consistent with Sections 2.1b and 2.2E of the DA Charter.
Request Details:
Broad outline of the Cylab project
Scope of the Cylab project e.g.
-- which code base vNow, vNext or both and rationale
-- Will Cylab deploy the code base themselves or use another method
-- what tools will be used
-- Who from the community or foundation is working with Cylab
-- What is the intended deliverable and when , CVE process, penetration test results i.e. what is planned
Deadline: The DA needs to be briefed on this as soon as possible
Impact (Teams): any security project has the potential / likelihood of affecting large parts of the project
Impact (Components): codebase , deployment and entire environment >
Some discussion from slack is inserted here for reference:
from James: in this case, MLF believes the core team are the "relevant stakeholders" who are given the results and coordinate fixes, release and sharing of results after the fact.
From James: note that there may be other "relevant stakeholders"...e.g. anyone using Mojaloop in situations where vulnerabilities may be significant. We are discussing this internally (input welcome), but my general feeling so far is that means folks using it in PoCs and/or production)
from Tom: no problems with the vulnerability disclosures from this being kept closer to chest and again very glad this is happening and happening by someone like Cylab. All that is good and encouraging as you and Sam are aware and as anyone who listened to my cloud native deployment work-stream presentation at the last convening will know security is something I am urging both the foundation and the community to focus a LOT more on. So far so good. Let me leave this thread here and raise this more generally as a DA ticket as , now that I know we (collectively) are starting to pay this area more attention I think that it is something that the DA should also be contributing to and I will see if others at the DA feel similarly. Cheers James.
from Tom: looking at the doc you linked above 2.1 Reduce harm bullet #1: "Publishing vulnerability information. Providing high-quality, timely, targeted, automated dissemination of vulnerability information enables defenders to make informed decisions and take action quickly."
2.3 Avoid Surprise : As with most situations in which multiple parties are engaged in a potentially stressful and contentious negotiation, surprise tends to increase the risk of a negative outcome. The importance of clearly communicating expectations across all parties involved in a CVD process cannot be overemphasized.
I still have no issue with keeping the new discovered actual vulnerabilities close but the doc you linked seems to support a much more open collaborative approach for example look at section #4.2. Anyhow I will desist here and move to DA.
(James please feel free to add more if I have lost any context from the slack conversation)
Request Summary:
It seems to be in the scope and charter of the DA to be kept appraised of any significant changes or projects that concern security of the Mojaloop code or environment. So the DA should request a briefing on the current security project being undertaken by Cylab. This seems to be very much consistent with Sections 2.1b and 2.2E of the DA Charter.
Request Details:
Broad outline of the Cylab project
Scope of the Cylab project e.g. -- which code base vNow, vNext or both and rationale -- Will Cylab deploy the code base themselves or use another method -- what tools will be used -- Who from the community or foundation is working with Cylab -- What is the intended deliverable and when , CVE process, penetration test results i.e. what is planned
Deadline: The DA needs to be briefed on this as soon as possible
Impact (Teams): any security project has the potential / likelihood of affecting large parts of the project
Impact (Components): codebase , deployment and entire environment >
Some discussion from slack is inserted here for reference:
(James please feel free to add more if I have lost any context from the slack conversation)
Artifacts:
Dependencies:
Accountability:
Decision(s):