feat: add in new metadata-based heuristic to pypi malware analyzer

[art1f1c3R]

This PR adds in a new heuristic to the PyPI malware analyzer that focuses on identifying anomalistic version numbers. An anomalistic version number is classified as one that is unrealistically high for a single release. This heuristic depends on the single-release heuristic, and currently implements thresholds for determining suspicious version numbers on the epoch, major, and minor version components. Versioning numbers must adhere to the PyPI standards (PEP 440, as per the packaging module), otherwise they will not be analysed.

This heuristic attempts to identify the versioning pattern to reduce false-positives. Calendar versioning is defined as a versioning pattern where the major is in the form of YYYY or YY, the minor is in the form of MM or M, and the micro in the form of DD or D, with no other release components (i.e. in the form YYYY.MM.DD only). These values must correspond to the upload time with a 48-hour window for time differences to be classified as calendar versioning.

Calendar-semantic versioning is defined as a versioning pattern where the major is in the form of YYYY or YY, but all other components are not detected as calendar versioning. All other versioning patterns are classed as semantic versioning.

Outstanding tasks for this PR:

• run Macaron with this new feature to determine suitable default thresholds
• make the thresholds configurable through defaults.ini

[art1f1c3R]

5537 existing PyPI packages with a single release were analyzed for their epoch, major, minor, and micro version numbers. From the results, all packages used an Epoch number of 0 (the implied epoch number as none supplied one). The data for major, minor, and micro version numbers included too many anomalies to plot nicely. From the data, the following changes will be made:

• Minor and Micro versions are not worth analyzing as they can contain many obscure values that are intended to be interpreted in a different way (e.g. aggregateGithubCommits with version 3.20200806 where the minor is actually a date, or annize version 5.0.6379 published May 31 2021). They are a less likely attack vector as to guarantee being prioritized over another package.
• The epoch threshold will be lowered to 3. The purpose of using an epoch is generally to ensure changing versioning systems prioritizes the new versioning system. It will still be included as it is a realistic attack vector, since most packages do not use an epoch at all.
• The calendar versioning will be updated to account for different ordering (e.g. YYYY.MM.DD or YYYY.MM.DD or DD.MM.YYYY), with a motivating example of abbrfix with version 26.2.2024 published on February 27 2024
• The threshold on the number of days of error allowed for calendar versioning will be increased to 4. A motivating example is aiocmdline version 2024.1.25 released on January 28 2024.
• The major version number may be checked to represent a date itself (e.g. andronnlib version 160122 published Jan 18 2022)
• The restriction for calendar versioning to only have 3 release components will be removed. A motivating example is aigc with version 2023.2.15.14.18.59 published February 15 2023. Checking the implied major version from this (14) is unnecessary as the date would be prioritized over this.
• The major version threshold of 20 will be kept. Many version numbers around this range are often calendar-serial or calendar versioning for the year (e.g. adwords-client version 17.7 published July 13 2017), so any major version number not corresponding to the calendar year here and above this threshold is sufficiently large to be considered suspicious.

There were some anomalies to these rules (e.g. almavik version 362 published June 24 2023, or abqpy2016 to abqpy2025 all versions 20xx.7.9, all published Dec 8 2024), but not enough to warrant relaxing the threshold.

[art1f1c3R]

I am going to request review on this as I don't believe an integration test may be appropriate for this feature, since there is no guarantee that any given package may be assumed to always have one release, so if I use a package for the test if it releases a new version the test no longer makes sense.

[tromai]

LGTM. Thanks!