In reply to JoshOvki:
> Still made me wonder if it would actually stand up to scrutiny though
For those of you know are unaware of this works:
- By virtue of the fact that not all vulnerabilities in code are known (and never will be) and the fact that more code is written every day .. no one, the world over, can ever say that their site is currently 100% secure or free from bugs or viruses OR that it will stay that way for any length of time. The only correct thing to assume is that your site is never secure and treat it accordingly.
- There is an entire industry that exists around the business of finding bugs in code. Some are good guys who want to help everyone else .. some are bad guys that want to exploit the vulnerabilities for their own ends.
- As new vulnerabilities are found by the good guys they are publicized. Here is an example - the original Log4j vulnerability that kept us all very busy immediately before Xmas: https://nvd.nist.gov/vuln/detail/CVE-2021-44228
- Once found, vulnerabilities are given a score from 0 -> 10 referred to as their Common Vulnerability Scoring System (CVSS) - https://en.wikipedia.org/wiki/Common_Vulnerability_Scoring_System
- Broadly speaking ... companies will apply a ranking, of there own determination, to the CVSS score and fix accordingly. Something like:
- 9/10 = CRITICAL. 2 days to patch for critical or public facing code / 7 days to patch for everything else (where I work)
- 6/7/8 = HIGH. 4 days to patch critical/public or 15 days to patch internal (where I work)
- 3/4/5 = MED. 15 days to patch critical/public or 45 days to patch internal (where I work)
- 1/2 = LOW. etc etc etc.
- So once you've got your code ... you can scan it/pen test it ... get your vulnerability assessment back - and then you need to determine what to do about it.
- Practicality of running any code is that you're always going to take a risk based approach. You don't go to production with criticals, you likely can't go to production without security team sign off for the highs, mediums you might get away with as long as you commit to fixing them in the next release and the lows you get to round to .. maybe ... one day.
Bottom line though ... no code can be considered "secure or free from bugs or viruses". That's just a fact of how this game works.
(For those of you particularly bored. A vulnerability was found in mid December referred to as "Log4Shell". The vulnerability was found a logging library called Log4j - an exceptionally widely used library that comes from the Apache foundation. The Log4Shell vulnerability discovered in December was a 10/10 = CRITICAL - relative rare. 10/10 means a couple of things 1) Needed no elevated access to exploit it, 2) It was very very easy to exploit it, 3) after exploitation it was conceivable that you could take full control of the device. In addition - this was a vulnerability in the wild and they new the bad guys were trying to exploit it as they announced this, in some cases successfully, and Log4j library was a foundational building block of half the internet i.e. impact was potentially going to be exceptionally wide. I understand that at one point it was considered a national security issue. I can only imagine that a significant portion of all software engineers the world over were engaged in some capacity in December in the resolution of this - one way or another. The issue was compounded by the fact that a fix for the original vulnerability was made available very promptly after the original vulnerability was found ... however they promptly found a 9/10 critical vulnerability in that too .. which meant a lot of code needed patched a second time. A moving target.)
