I believe this is my first time posting to this list, so apologies if I'm stepping out of line.
These comments are focused on the looping once aspect of this discussion. There is perhaps a 2nd aspect at play in Kurt's example with confusing naming, but I'm setting that aside for now. I feel like a loop that will always execute once should be considered a weakness. In the best case of "planning for the future" it reminds me of the code smell Speculative Generality, just at a lower level. At the very least it needlessly increases complexity and slightly hampers readability, and we have several CWEs that target other weaknesses for those reasons. It is worth stressing that just because a loop executes once does not mean it has this same problem. The problem is when the loop will always execute and always execute just once. Given the CWEs mentioned so far I think I like 1164 "Irrelevant Code" the best, but I feel like this particular issue should live under the 1226 "Complexity Issues" category. I suppose a very weak argument could be made for CWE 1121 "Excessive McCabe Cyclomatic Complexity". But a single loop is basically linear so that's quite a stretch. As a side note, we have run into several cases of other issues where the best match for something we were looking at was one of the members of "Complexity Issues", but the "excessive" part didn't really fit. Thanks! Kevin ________________________________ From: Steven M Christey <co...@mitre.org> Sent: Tuesday, May 24, 2022 4:49 PM To: Seifried, Kurt <k...@seifried.org>; Grubb, Steve <sgr...@redhat.com> Cc: CWE Research Discussion <cwe-research-list@mitre.org> Subject: [External] - RE: Bad loop construct CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Just some quick comments on this topic. It’s an interesting observation about shell languages being different than C. I know I’ve probably offended some co-workers recently with my initial attempts at bash scripting 😉 It feels to me like the syntax is somehow less stringent, but maybe the key difference is in interpreted languages versus compiled languages, combined with the lack of strict typing. Kurt said “I've seen code with loops of one because of future growth, or because various options were removed and it's easier than refactoring the code” – so a CWE-related writeup wouldn’t want to inadvertently call all loops of size 1 “bad.” But remember that a weakness is about a <mistake> that only becomes a vulnerability <under the right conditions.> Code analysis tools report weaknesses all the time, but determining false positives is a different story that’s not in CWE’s purview. Similarly, external parties can decide which CWEs become a “requirement” or not – it’s primarily CWE’s responsibility to provide the identifier and explanation for the mistake, and how it can (at least sometimes) contribute to vulnerabilities. In this “dir” example, we can’t be clear whether the developer made a mistake or not. But we can observe that there’s a loop construct with only one element, and that it’s (sometimes) going to be a mistake. And it seems like such constructs could occur in most languages. I’m not sure how deep CWE should go to cover “just bad syntax,” but for this example, I think CWE-670 is probably the closest match in spirit – the algorithm (probably) isn’t implementing the logic that the programmer thought they were implementing. There’s a good argument for CWE-1164 as well, though, since the developer might be doing this intentionally even though the code is not technically essential. For issues where there might be some varying opinions about whether some code choice is “good” or not, note that we also cover source code conventions with CWE-1078: Inappropriate Source Code Style or Formatting. It has some useful children. - Steve ________________________________ The information contained in this e-mail and any attachments from COLSA Corporation may contain company sensitive and/or proprietary information, and is intended only for the named recipient to whom it was originally addressed. If you are not the intended recipient, any disclosure, distribution, or copying of this e-mail or its attachments is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by return e-mail and permanently delete the e-mail and any attachments. COLSA Proprietary
