Preventing/Mitigating Open Source Supply Chain Attacks #88
Comments
|
Guideline from Snyk - https://snyk.io/blog/publishing-malicious-packages/ |
|
Top line is to:
|
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
I think we could look at developing a whitelist or something of that nature, but I think in general we should focus on best practices around code reviews, and have a culture around being skeptical when a new package is being added.
|
|
Thanks @lewisdaly for this input and we will keep this open until we decide additional package check measures to compliment existing checks which may not sufficient to prevent this types of attacks. |
|
Hi @MichaelJBRichards and @mdebarros Initially we thought we can prevent these types of attacks based on our current NPM package checking measures but upon reflecting on this again Lewis suggested to explore additional measures above which we can discuss in our DA meeting so lets keep this open for a while! |
|
Geoffrey?? Godfrey!
M
On Wed, 27 Apr 2022 at 08:03, Michael Richards <
***@***.***> wrote:
… Thanks for that, Geoffrey. Should we expect an investigative action as a
consequence of this? If so, whose responsibility would it be?
Yours,
Michael
On Wed, 27 Apr 2022 at 07:56, Godfrey Kutumela ***@***.***>
wrote:
> Hi @MichaelJBRichards <https://github.com/MichaelJBRichards> and
> @mdebarros <https://github.com/mdebarros> Initially we thought we can
> prevent these types of attacks based on our current NPM package checking
> measures but upon reflecting on this again Lewis suggested to explore
> additional measures above which we can discuss in our DA meeting so lets
> keep this open for a while!
>
> —
> Reply to this email directly, view it on GitHub
> <#88 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ALMZW4UKCZXITMWYLKUZLADVHDQJXANCNFSM5SUYE5KA>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
--
[image: Modusbox_Logos_Modusbox_Vertical_2C.png]
<http://www.modusbox.com/>
Michael Richards, Financial Services Principal
ModusBox,
7525 SE 24th St., Suite 510,
Mercer Island, WA 98040, USA
+ <+44%207785%20360009>44 7785 360009 ***@***.***
***@***.***>
--
[image: Modusbox_Logos_Modusbox_Vertical_2C.png] <http://www.modusbox.com/>
Michael Richards, Financial Services Principal
ModusBox,
7525 SE 24th St., Suite 510,
Mercer Island, WA 98040, USA
+ <+44%207785%20360009>44 7785 360009 ***@***.***
***@***.***>
|
|
Ownership is me and Lewis and participation is everyone in the DA @MichaelJBRichards |
|
Decision today: @lewisdaly to investigate how we can better use our process around |
|
I've done some more digging around our existing integrated tools, and here's a summary on my latest thinking: Goal: Determine how we can use our existing tools: Questions I think we all want to answer:
Did we just get lucky on the last n npm hacks/flaws? Or is our processing working?I need to come back to this - my plan is to look at the last Whitesource Audit and see if some of the more recent NPM flaws show up. It's hard to look back in time for security issues since we don't know if we (1) never depended on a given malicious module, (2) depended on a malicious module but our tooling works. How can we make our process more robust to protect the codebase without adding too much governance (e.g. whitelisting npm packages) or work?Case Study: EJS
My lowest-hanging-fruit proposal here is:
e.g.: npm audit fix
# after running
# 15 vulnerabilities (3 moderate, 12 high)
# this command passes
npm audit --omit=dev --audit-level=critical
# this command fails:
npm audit --omit=dev --audit-level=high |
Whitesource vs NPM Audit
White these numbers may not line up at a top level, the discrepencies can be explained by:
|
|
SBoM work helps mitigate...Moving to review, new ticket(s) to be opened to cover specifics if necessary. |
|
Hi @bushjames, SBOM is just a listing of what is used to build the software, which is one of the many steps required in the open-source risk chain. Since this is pretty old, you can close it, and it could be re-opened in a new context. |
|
Update from @elnyry-sam-k: SBOM progressing well. To be presented at upcoming DA call. Work on provenance of all mojaloop dependencies and artifacts is in progress. Some recommendations have been made which are being assessed. |
Request Summary:
Open Source Module Supply Chain attacks pose a real risk to the community:
For example: https://www.zdnet.com/article/corrupted-open-source-software-enters-the-russian-battlefield/
In this case, a malicious package was inserted as a dependency for a widely used package, which ended up attacking users who had ip addressed in Russia.
How can we as a community best prevent these sorts of attacks from affecting the Mojaloop Community?
Request Details:
Artifacts:
Dependencies:
Accountability:
Decision(s):
Details
Follow-up:
The text was updated successfully, but these errors were encountered: