Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Wednesday July 22 2020, @03:18AM   Printer-friendly
from the go-for-a-record dept.

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.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 0) by Anonymous Coward on Wednesday July 22 2020, @06:53AM (5 children)

    by Anonymous Coward on Wednesday July 22 2020, @06:53AM (#1024875)

    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)

    by Opportunist (5545) on Wednesday July 22 2020, @07:23AM (#1024879)

    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)

      by Anonymous Coward on Wednesday July 22 2020, @09:37AM (#1024892)

      It's technically possible to test for all possible inputs, if you already limit the number of possible inputs.

      Ok. So,

      struct things {
          char hostname[MAXHOST];
          int port;
          char path[MAXPATH];
      };

      bool func(const struct things *)
      {
      }

      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

        by Anonymous Coward on Wednesday July 22 2020, @08:15PM (#1025082)

        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)

    by Anonymous Coward on Wednesday July 22 2020, @09:36AM (#1024891)

    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

      by Opportunist (5545) on Wednesday July 22 2020, @11:38AM (#1024906)

      I did not say it was sensible or even feasible. I just questioned that it is not possible.