Captain, we've detected a disturbance in space-time. It's coming from Earth. Someone audited the Kubernetes source The Cloud Native Computing Foundation (CNCF) today released a security audit of Kubernetes, the widely used container orchestration software, and the findings are about what you'd expect for a project with about two million lines of code: there are plenty of flaws that need to be addressed. The CNCF engaged two security firms …
"Kubernetes... originally designed by Google, the company that loves to announce other companies security issues before they have time to release a patch."
If 90 days is not long enough to patch vulns, then your vendor is trash, and should be forced to close.
If unfixed vulns are not disclosed after a strict time limit, it would eventually lead to another NSA type of vuln hoarding situation.
What is a line of code?
Does it include a comment? A curly brace all on its own on a line? Is a simple variable declaration counted as a LoC ?
I have code in front of me with a nesting level so that the end of it looks like this
}
}
}
}
}
}
}
}
Is that really 8 lines of code? (the website has removed the indenting, but they sloped in from top right to bottom left.)
This would work just the same as far as the compiler cares: }}}}}}}}
Just wondered is 2 million LoC really is 2 million.
The figure is just the total number of lines in the source code as reported by a text editor. As such it will include all you mention, plus even blank lines. It is just a very rough indication of the size of the project, and cannot be used to compare between two different projects or as an absolute measure. Some programmers will use many comment blocks and separate functions with blank lines to improve readability, and will not try to put too much functionality into a single line of code.
Other programmers skimp on comments and layout, while putting as much functionality into each line as possible. It can end up producing near-identical binaries as the more verbose code, yet contain less than 25% the number of lines of code.
Even if you were to measure size by using a character count of only the parts of source that the compiler uses, the size will depend on things such as what labels for variables etc. were chosen, e.g. "Intermediate_subtotal_amount" as opposed to "Subtot" or even "ST"
.
With the ubiquity of tools like "cloc" that count actual lines of code (iow, statements; it will also report blank lines and comment lines separatly), I'd hope that this is what they're talking about.
Golang is one of these languages that really likes to pull in lots and lots of library dependencies; I wonder whether all these dependencies, recursively, have been audited as well.
Paying by the number of lines of code is an insane idea.
It would be very easy to "expand" a "few" lines of code to a "Lot" of lines of code without changing what it does. Does that mean i get more money. I hope not.
Code should be just the right number of lines.
Meaningful variable and method names, Comments where approriate to help anyone else that has to maintail the code and the code laid out sensibily.
Anyone that tries to squeeze as much functionality into each line of code for no other reason that bragging rights should be shot.
Code should always be written with the assumption that it is NOT you that will make any changes.
Anyway, going back you your own code months or years later can be hard enough, especially if you failed to be clear.
I know of one programmer that was paid by lines of code. 5 years after he had left the company I was brought in to make changes based on Aussie GST . A project that was likely to see me on nonstop coding marathons that would impress a speed freak.
It was the most commented/documented code I have ever seen.
Project turned out to be a breeze. Not only commenting on purpose of code block , but flow on dependency effects to other blocks of code. Pitfalls, limitations, references. You name he had in there.
That one programmer and his pay by line, saved that company millions in changes 5 years later and millions again over another 5 year period in additional changes and enhancements.
Food for thought on the the concept of Pay by line .......
Hope not.
Slight aside: Back in the pre-F77 days, the IFTRAN preprocessor was a popular way to do structured coding for FORTRAN programmers. If one used the PDP compiler option that produced the equivalent MACRO-11 code, you noticed that every ENDIF statement resulted in a NOP instruction inserted into the code as the target for some form of JMP instruction (for the case when 'IF (...)' was 'false'). Heavily nested IF-ENDIF statements would result in a series of NOPs in the executable code. Even if every IF statement in the 'nest' evaluated as 'true', eventually the CPU would hit all those NOPs and spin its wheels for a few clock cycles.
34 vulns in 2 million loc is very very good. Industry average for bugs (I know it's apples and oranges but I'm not aware of a metric for *vulns* per 1000 loc) is somewhere between 15 and 50 per 1000 loc, so a security issue per 58,823 loc is pretty good if you ask me.
That they've done the thing out in the open, and are already patching the issues speaks volumes, IMHO. Beers.
1) Bugs are not the same as vulns. Not even a little bit. In particular, many vulns are not actually bugs at all. While lots and lots of bugs are not vulns.
2) It's not the quantity, or even the quality of the vulns (or bugs) that matter. It's the nature of the processes that allowed the events to occur. The described list suggests some very sloppy development processes. If these are not addressed, we can expect more of the same.
Claptrap! Any deviation from expected or intended function is a potential vulnerability (or opportunity from an attackers viewpoint). The key message is that you only need a single critical exploitable bug in ANY system, no matter how simple or complex. The fact is that more complexity invites more opportunities for bugs and 17 per million lines of code seems very high quality to me. Software defects are almost always security defects it's just a case of how exploitable they are over time.
Note that multiplier.
1000, not 1000 000. That would be about 68 thousand vulns on industry standard error rates in this size of code.
So on that basis, actually pretty good code.
Now was that just luck? Having a (smallish) team of high quality developers?
Or was it a well developed process to design it, develop it and then put all the parts together in a methodical way?
One is the "artisan" model of development. The other is the "engineering" model. There is still plenty of room for creativity in the engineering model, provided it's funneled into the task properly.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
