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.



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 

- 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

Reply via email to