...
| Code Block | ||
|---|---|---|
| ||
def set_score(severity_df: pd.Series):
"""
Helper function to claclulate the score metrics
:param severity_df: DataFrame object with statistics based on GH Sec issues
:return: malus (how much to deduct from the optimal start value)
"""
malus = 0
for key, value in severity_df.iteritems():
key = str(key).lower()
# this requires python 3.10
match key:
case "critical":
malus = malus + 4 * value
case "high":
malus = malus + 3 * value
case "moderate":
malus = malus + 2 * value
case "medium":
malus = malus + 2 * value
case "low":
malus = malus + 1 * value
case _:
sys.exit("Unknown key:" + key)
return malus |
Report for example 100 - malus.
Limitations of the approach
There are more sophisticated scoring approaches.
Veracode has a specific application profile setting based on the use case of the product, risks, architecture etc.
GitHub Security doesn’t even distinguish between a NodeJS frontend (Angular) and Backend project ( )
. At a certain site and complexity of the service platform, you will need different approaches.
But you can still start this way and expand later.
With GitHub Security application profiles for PCI DSS or other standards cannot be defined (unless you’re at an SAQ-A, where this can suffice)
you can read the standards and document your decisions (in the tickets)
GH Sec is too generic and QA focused for PSP or critical infrastructure security (imho)