feat(scoring): Implement dedicated scoring logic for URL analysis

[AxelSecurity]

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)

Motivation and Context

Currently, the calc_scoring function in lib/cuckoo/common/scoring.py has a detailed, category-based logic for executable files. However, analyses for URLs (category: "url") fall into a generic else block.

This leads to two main issues:

1. The score calculation is basic and does not differentiate URL-specific threats.
2. More importantly, the status variable is never assigned for non-executable analyses, resulting in a None status in the final report, which is unhelpful for users and integrations.

This PR aims to fix this by implementing a dedicated and complete scoring logic for URL analyses.

Description of the Change

This pull request introduces a dedicated logic path for URL analyses at the beginning of the calc_scoring function.

1. It first checks the analysis target's category via results.get("target", {}).get("category").
2. If the category is "url", it enters a new block that performs the following actions:
   • Calculates finalMalscore based on the matched signatures' weight, severity, and confidence.
   • Adds support for the maximum attribute in signatures, allowing a single high-impact signature to set the score directly.
   • Crucially, it assigns a status (Malicious, Suspicious, Clean, or Undetected) based on the final score.
   • It then returns the score and status immediately, preventing the analysis from falling through to the file-specific logic.

This ensures that URL analyses now produce a meaningful score and a clear, human-readable status, significantly improving the quality of the analysis report. The existing logic for executable files remains untouched.

How to test

1. Submit a URL for analysis (e.g., a known phishing site or a benign site).
2. Ensure the analysis triggers some signatures (e.g., network or phishing related signatures).
3. Check the final report. Verify that the analysis now shows:
   • A calculated score (e.g., > 4.0).
   • A corresponding status (e.g., Suspicious or Malicious) instead of None.

Checklist

• My code follows the style guidelines of this project.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• I have made corresponding changes to the documentation. (N/A for this change)
• My changes generate no new warnings.

[gemini-code-assist]

Summary of Changes

Hello @AxelSecurity, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances the calc_scoring function by introducing a specialized scoring mechanism for URL analyses. Previously, URL-based reports lacked detailed scoring and a meaningful status. The changes ensure that URL analyses now yield precise scores and clear, human-readable statuses, thereby improving the overall quality and utility of analysis reports without affecting existing file-based scoring logic.

Highlights

• Dedicated URL Scoring Logic: Introduced a new, dedicated logic path within the calc_scoring function to accurately calculate scores for URL analyses. This addresses previous limitations where URL analyses fell into a generic else block, providing a more specific and relevant scoring mechanism.
• Meaningful Status Assignment: Implemented the assignment of a clear, human-readable status (Malicious, Suspicious, Clean, Undetected) for URL analyses. This resolves the critical issue of None status in reports, significantly improving report clarity and utility for users and integrations.
• Signature maximum Attribute Support: Added support for the maximum attribute in signatures specifically for URL analyses. This allows a single high-impact signature to directly set the final score, ensuring that critical findings are appropriately reflected in the overall score.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request effectively addresses a bug where URL analyses were not assigned a proper status, resulting in None in reports. It introduces a dedicated logic path for URL scoring, which is a great improvement.

My review focuses on improving the maintainability and robustness of the new code. I've identified a few key areas for enhancement:

• Code Duplication: The new URL scoring logic is very similar to an existing block, which could be refactored into a shared helper function to avoid future maintenance issues.
• Code Clarity: I've suggested removing temporary comments, translating a foreign-language comment, and using more concise Python idioms.
• Robustness: A small suggestion to make the handling of the maximum signature attribute safer.

Overall, this is a valuable change that fixes an important issue. Addressing the feedback will make the code even better.

[AxelSecurity]

All feedback has been addressed. The code has been refactored and cleaned up. Thanks for the review!

[kevoreilly]

Happy days! Thanks a lot for this contribution. I'll wait for doomed to double check when he's back from vacation, but all looks good to me 👍