Description of AV-301 is too much geared towards AV-304

[henrikplate]

I think that the current description of AV-301 is not general enough and too close to its child node AV-304, esp. by the emphasis on immature vulns, and that the vector is "limited" to introducing backdoors.

IMO, the description could be widened or generalized to to consider all kinds of malicious contributions, e.g. introducing a new malicious dependency, new functionality, test cases etc.

[piergiorgioladisa]

I agree, so what about changing the description as follows:

A malicious code injection can occur within a project when a seemingly benign patch, designed to address an issue, is trojanized. This injection might introduce various elements, such as the completion of an immature vulnerability condition or the addition of a new (malicious) dependency, new functionality, or even malicious test cases.

In the first version of the taxonomy (i.e., before the survey) we had two nodes that then were merged in the new node AV-301. Such nodes were:

• Hide in Pull Request. This node existed to cover exactly the cases you mentioned. Since this was covered in general by the current parent node Introduce Malicious Code through Hypocrite Merge Request, I think it was the main reason why we dropped it.
• Introduce Vulnerability through Pull Request

Another option is to add new nodes below AV-301 (thus siblings of AV-304) like "introducing a new malicious dependency," "introducing malicious code through new functionality," and "introducing malicious code through test cases" to the taxonomy. However, we should ensure to have credible references to support these techniques. This is important for the correctness and reliability of the taxonomy.

[henrikplate]

I think it does not make sense to add new nodes below AV-301 for every single possible contribution. There are so many things that can be introduced, e.g. dependencies and test cases but also CICD definitions etc., that we will never be complete.

What about the following new description of AV-301, where I tried to better distinguish between the pretended contribution (functionality, test case etc.) and the malicious code, esp. what it is (deliberate vuln. or "active" malicious code) and where it is (in project code or hidden in a dependency.

Attackers can pretend to make a useful, seemingly benign contribution to a project while in fact submitting malicious code. For example, the contribution can pretend to introduce new functionality, test cases, CI/CD automation or documentation. Contributions for some of those topics may be reviewed with less scrutiny by legitimate project maintainers, which may be exploited by attackers.
The malicious code itself can expose malicious behavior (e.g. a dropper) or be a deliberate vulnerability, which can be exploited at later stages. It can be included in project code or hidden in newly introduced dependencies.

[piergiorgioladisa]

Fine for me, I think we can change it like you proposed.