New weaknesses regarding 3rd party libs

[Diolor]

Description

Adds 2 new WE placeholders regarding 3rd party libraries. I could not find any similar WE.

1. WE-xxxA is the placeholder for TG-0004 #2942

Explanation: this weakness uses the same logic there is in WE-53, WE-54, WE-55. See https://mas.owasp.org/MASWE/#q:sensitive%20data%20leaked
This currently focuses on P but can be rescoped.

2. WE-xxxB is a new weakness regarding known vulnerable libraries via supply chain best practices and SBOM checks

[cpholguera]

As discussed: it relates in a way but the New weaknesses could be something like "Dependencies Known to be Malicious". It could leverage the SBOM (from the dev side or from binary analysis) and consult a malware DB.

[Diolor]

@cpholguera and @sushi2k I rewrote these WE placeholders. I rewrote WE-xxxB to given feedback. Let me know if should consolidate WE-xxxA with some other WE, so far I didn't something relevant, therefore I suggest we add it.

Check updated description above

[cpholguera]

The fact that the library/SDK is malicious should be irrelevant as weaknesses are generic. The focus here should be put on the fact that the app includes libraries/SDKs already known to be malicious. Regardless of what exactly they do. Those "bad" things they do should be all covered by other weaknesses.

[Diolor]

Fair. I rewrote the the placeholder with that in mind. I also found existing
https://mas.owasp.org/MASWE/MASVS-CODE/MASWE-0076/ which targets Vulnerabilities in libraries. Therefore we could add this new WE or consider expanding existing WE-0076 as impact and mitigations (in a brief look) are close if not similar

[sydseter]

This reads more like an attack pattern than a weakness e.g: "CAPEC-533: Malicious Manual Software Update". What is the weakness that causes someone to use dependencies known to be malicious? I think the weakness we are looking for is something along the lines of "CWE-494: Download of Code Without Integrity Check", or "CWE-1395: Dependency on Vulnerable Third-Party Component", but rewritten in a mobile context. These should, however, already be covered by MASWE-0076.

[sydseter]

Should this instead be something like:

Embedded Malicious Code? https://cwe.mitre.org/data/definitions/506.html

The malicious code doesn't necessarily need to be part of dependencies. It could, as you say, be an insider.

[Diolor]

Thanks for the thoughts @sydseter!

According to our project, a weakness is "a security or privacy issue that can be introduced into a mobile application". With that statement as an anchor, I would reformat the question a bit to: "What is the security or privacy issue that can be introduced into a mobile application?"

For that question, our answer can be "Embedded Malicious Code" (like CWE-506) or "Dependencies Known to be Malicious". The second one is a bit more aligned with our existing 0076, but for me, both read fine.

"What caused someone to use dependencies known to be malicious?" is more of an introduction.

Another benefit of treating this as a separate WE is the distinction between malicious and vulnerable code:
At first glance, they may have similar methods of introduction (MoI), but e.g., supply chain attacks as a MoI (like namespace confusion, typosquatting, or malicious code injection) may be seen only in malicious libs. Similarly, "Outdated Platform Security Components" (from MASWE-0076) is more of a vulnerability MoI and not a malicious lib one.

Given the above, are you satisfied with this current state, or do you have any change suggestions on your end for this MASWE?

[cpholguera]

CODE?

[Diolor]

updated to CODE-3, which was the closest to this group. Also updated the CWE.
let me know if we should keep this L1, L2 or R should also be considered