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: 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.