Does this count as a vulnerability?

[Josh Bressers]

Hi all,

I ran across this tonight

https://github.com/qpwo/actual-malware

Is this something that deserves a vulnerability ID?

The library is very clear what it does.

--

     Josh

[Marcus Meissner]

It does not violate security assumptions -> I would say "No".

Ciao, Marcus

[Kurt Seifried]

Can you clarify what those “security assumptions” are? As an industry we often use terms without them being defined.


-Kurt





> On Mar 19, 2022, at 5:23 AM, Marcus Meissner <meis...@suse.de> wrote:

>
> On Fri, Mar 18, 2022 at 08:15:26PM -0500, Josh Bressers wrote:
>> Hi all,
>>
>> I ran across this tonight

>> https://www.google.com/url?q=https://github.com/qpwo/actual-malware&source=gmail-imap&ust=1648293818000000&usg=AOvVaw2yoVE5WLJIQVC4gsADI7bX

[Josh Bressers]

I'm pretty comfortable agreeing it's not a "vulnerability". I think the term has taken on a rather baroque quality for describing security bugs.

That said, I think it is a piece of software that any sensible security practitioner would want to be made aware of on a system. This is that sort of grey area we discussed in the last GSD meeting. Security bugs are really a sliding scale. Historically we've treated them as binary which explains our strict legacy definitions.

-- 

     Josh

--


<https://cloudsecurityalliance.org/research/working-groups/quantum-safe-security/>
This e-mail account is used only for work-related purposes; it is not
guaranteed that any correspondence sent to this address will be read by the
addressee only, as it may be necessary, under certain circumstances, for
third parties appointed by the Cloud Security Alliance to access this
e-mail account. Please do not send any messages of a personal nature to
this address.

[Kurt Seifried]

On Sat, Mar 19, 2022 at 6:22 PM Josh Bressers <jo...@bress.net> wrote:

I'm pretty comfortable agreeing it's not a "vulnerability". I think the term has taken on a rather baroque quality for describing security bugs.

That said, I think it is a piece of software that any sensible security practitioner would want to be made aware of on a system. This is that sort of grey area we discussed in the last GSD meeting. Security bugs are really a sliding scale. Historically we've treated them as binary which explains our strict legacy definitions.

Stupid question but what separates this from:

node-ipc

https://nvd.nist.gov/vuln/detail/CVE-2022-23812

 "ASSIGNER": "rep...@snyk.io",

is it simply that node-ipc was not announced as having malicious code, but "actual-malware" was?

Also I keep seeing people use terms like "legacy definitions" and "security assumptions" without actually saying what they are. I think this is a big part of the problem, and one reason I want to have a pile of data to refer to, e.g. we may not be able to define "X" right now (if ever) but it's helpful if we have a pile of "clearly X", "clearly not X" and "we're not sure if this is X or not" which leads me to the "GSD all the things and tag the data so that sorting them out is easy."