SoylentNews is people
SoylentNews
Experts Predict Record 20,000 CVEs for 2020:
This year could see a record breaking 20,000 vulnerabilities reported, with major increases in mobile bugs already in 2020, according to Skybox Security.
The security vendor's midyear update to its 2020 Vulnerability and Threat Trends Report contains some concerning findings for organizations as they struggle to manage cyber-risk at a time of mass remote working.
With 9000 vulnerabilities reported in the first half of the year, the firm is predicting the final total for 2020 could top twice as much as that. The figure for new CVEs in 2019 was 17,304. Without risk-based automated patch management systems, organizations struggle to mitigate these issues, leaving them exposed to attacks.
Part of this increase is due to a surge in Android OS flaws: these increased 50% year-on-year, according to Skybox.
(Score: 2, Insightful) by Anonymous Coward on Wednesday July 22 2020, @05:11AM (18 children)
There's too much focus on testing in the software industry and not enough focus on working towards writing bug free code. You can't test yourself to a higher quality product when your code base is crap and if you write crappy code then your tests are going to be written with crappy code too.
Therefore even good testing practices won't be enough since your tests can't be trusted.
Believing someone who writes bug ridden code can magically write perfect tests and test the proper edge cases is simply craziness on the same level as believing your religion is the true one and all others are false because your parents said so. If you do believe that, then believe me when I tell you to stop spending your time learning new testing strategies and instead spend it learning to write quality code which manages all logic paths, checks all error conditions, and verifies all inputs/outputs at the function level (so all parameters and all returns). Do that and your code will tell you exactly when and where an error occurs as soon as that error occurs. No more hunting for bugs, let the software do the work for you by writing it properly in the first place. I have said this so let it be so from now unto forever and ever, and may your ending brackets always align;
(Score: 1, Informative) by Anonymous Coward on Wednesday July 22 2020, @05:50AM (8 children)
Proper testing is a key to writing bug free code. The problem is that people test the wrong things. Most tests are to make sure that "good" values get "good" returns. That is fine and all for a start, but if you never test bad input for proper errors you can come up short. Another is that people write for line/statement coverage and then smile when they get 100%. The problem is that they don't check branch coverage, let alone MC/DC or test all sides of comparisons or check for mutants or property test or fuzz. To borrow from an old joke, too many people check to see if ordering a beer returns a beer at the end, but they never check to see what happens with 0 beers, 999999999999 beers, -1 beers, NaN beers, a fish, a flsdja;rijdjr, or asking where the bathroom is. Another fun situation is where they actual end up testing their mocks instead of the real thing or not having actual integration or verification tests above the function level.
(Score: 1, Insightful) by Anonymous Coward on Wednesday July 22 2020, @06:10AM (1 child)
Testing only verifies how bug free your code actually is. Bug free code without tests is still bug free code (though it'd be harder to realize the code is bug free). Testing only aids in writing better code if you analyze why the bug occurred and how you can prevent that type of bug from being written in the future. If you simply squash each bug it uncovers without investigating then the quality of code you write in the future only improves at a snails pace at best.
We're not exactly agreeing with each other but we're not disagreeing either. I agree with everything you said after your first sentence but I see the 1st as more of a validation step rather than a requirement.
(Score: 0) by Anonymous Coward on Wednesday July 22 2020, @08:45AM
No, we completely agree. I was just pointing out that you can write bug free code if you do it right the first time, but that doesn't really mean anything if you don't know it. The problem I was trying to point out is that lots of people substitute improper values for "knowing it" and proper design/understanding.
However, I'm far to pragmatic in my understanding of people. You can tell me that you have accounted for the entire input space and every possible graph traversal because you were super careful, but without proof I don't really care. People make mistakes all the time and it is much harder to spot your own than another's. But you are right to point out that a lot of today's word is squash the bug and move on instead of understanding the "why" of the problem that may go much deeper.
(Score: 0) by Anonymous Coward on Wednesday July 22 2020, @06:53AM (5 children)
You cannot test for all possible inputs, it'll take forever and a day. You can test for what YOU think might be corner cases, but it is what you DIDN'T think could be one, that will be your code's downfall some undefined time later.
Note that other people's code that you call into, can grow new unimaginable corner cases basically anytime. External libraries can do it between any releases, no matter how minor.
(Score: 2) by Opportunist on Wednesday July 22 2020, @07:23AM (2 children)
It's technically possible to test for all possible inputs, if you already limit the number of possible inputs. If you whitelist characters and limit the length of the potential input, you can even determine how many cases you have to test.
(Score: 0) by Anonymous Coward on Wednesday July 22 2020, @09:37AM (1 child)
Ok. So,
Now write some test that will test all inputs to this nice function.
But maybe instead of doing stupid things, you should just read up some books about effective testing and unit coverage.
(Score: 0) by Anonymous Coward on Wednesday July 22 2020, @08:15PM
That's actually really easy. If you want to make a pedantic point, maybe construct an actual challenge.
(Score: 0) by Anonymous Coward on Wednesday July 22 2020, @09:36AM (1 child)
Depends on the function as to whether you can literally cover all possible inputs or not. But even if you can't, inputs can be divided into classes of inputs. If your control flow paths, conditions, decisions, and comparisons, are kept in mind, you can cover the entire possiblity for classes of inputs. This is where things like properties and mutations (and other advanced things like HOMs, profiling-fuzzes, or fault injections) can come in real handy.
As you mentioned, the real problem is when you call into other people's code. There must be real care there to verify what was returned. However, as mentioned, that just becomes an issue of verifying the classes of returned data and proper use of mocks or other fakes can help there too. As can having verification tests based on the classes of input you provide to their function calls.
(Score: 2) by Opportunist on Wednesday July 22 2020, @11:38AM
I did not say it was sensible or even feasible. I just questioned that it is not possible.
(Score: 2) by maxwell demon on Wednesday July 22 2020, @06:30AM
The important part here is “as soon as that error occurs.” The point of writing tests is to get as many bugs as possible occur in your test suite instead of after the code being employed, so you can fix them before your customer gets to see them.
Also, you also want to find bugs that currently can't actually be triggered because the current code happens to never call the function with the triggering parameters, but which could happen after a future change of the calling code.
Oh, and if you are not able to write correct tests in a test suite, you'll also not be able to test properly in-code. Also note that the person who writes the code is not necessarily the same who writes the test in the test suite.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 3, Informative) by Snotnose on Wednesday July 22 2020, @06:47AM
The key is the person who writes the code is not the same person that writes the tests.
When the dust settled America realized it was saved by a porn star.
(Score: 2) by bzipitidoo on Wednesday July 22 2020, @10:18AM (5 children)
There's also too much focus on "security" bugs. This whole idea of classifying bugs into two kinds: those that impact security, and all the rest, overlooks quality. To use an analogy with a building, it can be like worrying that the locks on the doors are in good order and the windows all latch properly, while ignoring that the A/C is broken, and the plumbing leaks. The first thing the occupants are going to do to keep the building as cool as possible is open all the windows and leave them open. It won't matter that the latches work great.
So then people may decide to count a broken A/C as a security issue. Keep going down that slippery slope, and pretty soon, almost every bug is a security issue. Some people are paranoids who contrive to link everything to security. The already dubious distinction is rendered useless.
If anything is like a wide open window, it's MS Windows. MS could do better, but they and their customers do not want to be inconvenienced. Then there's bugs such as the Spectre class of bugs in CPUs. There hasn't been a scramble to fully fix the security issue ASAP. They're only being "mitigated". The risk is low and no one wants to take the performance hit. Most especially, no one wants to go back to 25 year old CPUs that don't have speculative execution and therefore can't have the related vulnerabilities. So much for the overriding importance of security.
(Score: 2) by hendrikboom on Wednesday July 22 2020, @07:55PM
I suspect 15-year old CPUs will do.
(Score: 2) by takyon on Wednesday July 22 2020, @08:04PM (1 child)
Connecting to the internet is the problem.
Keep some computers off of the internet, and some on, with the expectation that the latter group could become compromised. But probably not all at once.
Just have a computer for every single task like that Mojibake Tenga guy.
[SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
(Score: 0) by Anonymous Coward on Thursday July 23 2020, @12:47AM
Or boot off of a read-only USB key with a (customized) live linux distro.
Every reboot is a fresh machine ... (If you check the hashes periodically)
(Score: 2) by hendrikboom on Wednesday July 22 2020, @11:14PM
A nonsecurity bug in one program may well cause a security bug in an otherwise correct program that relies on the first one to behave correctly.
(Score: 0) by Anonymous Coward on Thursday July 23 2020, @12:45AM
I am using a late model single core P4 with Freq scaling of 2.4 to 3.4 Mhz
The cache bugs are there if you try to test for them, but the CPU does not
have enough computing power to get reliable data out of the side channel,
and likely not a deep enough cache to make the attacks useable.
(Score: 2) by darkfeline on Wednesday July 22 2020, @08:07PM
>writing bug free code
And Other Hilarious Jokes You Can Tell Yourself.
There's no such thing as bug free code, only code in which we have not yet found any more bugs.
Join the SDF Public Access UNIX System today!