I'd like to work on this issue, here is my plan:

1. Implement core security settings functionality:

   • Get/update repository security settings (Advanced Security, Secret Scanning, Push Protection)
   • Manage Dependabot security updates (enable/disable/status)

2. Add five new tools following the project patterns:

   • get_security_settings
   • update_security_settings
   • get_dependabot_security_updates_status
   • enable_dependabot_security_updates
   • disable_dependabot_security_updates

I have already got a high level overview about this enhancement and its implementation, before I submit a PR, I would appreciate any recommendations or confirmations about:

• The tool names and structure
• Any additional security settings we should consider
• Any specific patterns or conventions I should follow

Small suggestion to make the dependabot pattern use update_dependabot_security_updates. Dependabot updates can be enabled or disabled, alongside paused.

As per GET /repos/{owner}/{repo}/automated-security-fixes:

{
  "enabled": true,
  "paused": false
}

Thanks for the suggestion @TotalDwarf03 , I see your point about the paused state in the API response, however, I decided to keep the separate enable/disable pattern for a few reasons:

1. While the GET endpoint returns both enabled and paused states, the actual modification endpoints in GitHub's API are separate:

   • PUT /repos/{owner}/{repo}/automated-security-fixes (to enable)
   • DELETE /repos/{owner}/{repo}/automated-security-fixes (to disable)

2. Having separate tools makes the intent more explicit for users, so instead of having to figure out what payload to send to an update endpoint, they can simply call:

   • enable_dependabot_security_updates when they want to turn it on
   • disable_dependabot_security_updates when they want to turn it off

3. The paused state is still accessible through the get_dependabot_security_updates_status tool, which returns the complete status including both enabled and paused fields:

{
  "enabled": true,
  "paused": false
}

Let me know if you would like me to adjust this approach or if you have any other suggestions, I'd be happy to hear from any existing contributor/maintainer as I started drafting the implementation.

I created a PR to share the implementation, I faced an issue that is explained in the PR, I built a docker image and pushed it to my own docker hub to test the tools in real time with an LLM client (copilot), here is what I faced:

To be more concise:

• Public repositories should have vulnerability alerts enabled by default
• When we check with get_security_settings, it confirms that vulnerability alerts are enabled
• However, when we try to enable Dependabot security updates with EnableDependabotSecurityUpdates, the API still requires explicit enabling of vulnerability alerts
• This creates a confusing situation where the system says one thing but behaves differently

This discrepancy is why I commented out the EnableDependabotSecurityUpdates and DisableDependabotSecurityUpdates functions and documented the issue in the code.

UPDATE

I created the PR for the sole purpose of sharing what I did so far, I am trying to figure out a solution to the issue of the remaining tools (EnableDependabotSecurityUpdates and DisableDependabotSecurityUpdates), but I would like to take insights from any maintainer/contributor so I can complete the PR.

Thanks for this, I actually had a draft PR for enabling some security features before launch. #52

What delayed me was that the API is not super well matched to what we would want to present here, but I intend to finish it soon. Some sibling properties like push protection also require secret scanning to be on first. Effectively I want to think this through carefully first. Part of the problem is also that there are many scenarios where it would fail (org hasn't purchased the product, banned by policy).

LMK if you have ideas on how best to model the interaction on the LLM side.

Thanks for your comment, to sum up issues are:

1. API behavior discrepancy with Dependabot alerts
2. complex feature dependencies
3. multiple failure scenarios

For now, we can:

1. implement our own validation and error handling for feature dependencies
2. adding clear documentation about feature requirements
3. creating an approach for the LLM to handle these scenarios

For example:

• add validation to ensure features are enabled in the correct order
• provide clear error messages about dependencies
• implement proper status checking before enabling features

would you like to collaborate on implementing these improvements? i can help with:

1. Adding dependency validation
2. Improving error handling
3. Creating a better LLM interaction model

We can create a wrapper around github API that validate and give clear status info, what do u think?

Sorry for the delay, I have had a lot of things to look at and the next couple of weeks are likely to be very busy too. I am certainly not against collaborating on your fork if needed to get the feature completed.

I do think it would be pretty cool to get this feature made. Making repos more secure with this is a nice touch.

No worries :) I created a PR for this issue if you looked at it by any chance you will see that I commented 2 tools in the code which had the issue you faced previously, so we can figure them out and im open to your opinion about them, regarding the rest of code works like a charm with my tests just needs reviews for any optimization.