Amazon Bedrock Pull Request Reviewer: Building Diffender

Last updated on July 13, 2026

A pull request can pass its tests, satisfy its acceptance criteria, and still expose a production credential in one line of code. Diffender is an Amazon Bedrock pull request reviewer built to identify that kind of risk before the change reaches the main branch.

However, human review remains essential, and its depth can vary with workload, time pressure, and security experience. Meanwhile, deterministic scanners provide valuable coverage, although their findings are not always presented in a form that developers can immediately understand and act on.

Diffender adds another layer to that review process. It is a serverless GitHub bot that receives pull request events, retrieves the changed code, asks Claude Haiku 4.5 on Amazon Bedrock to review the diff for security issues, and posts the findings directly on the pull request.

The name combines two ideas: diff, the code changed in a pull request, and defender, the security reviewer examining those changes.

What Diffender Does

When a developer opens, reopens, or updates a pull request, GitHub sends an HTTP webhook to Diffender. Amazon API Gateway receives the request and invokes an AWS Lambda function.

The function then:

Verifies that GitHub signed the request.
Reads the pull request details from the webhook payload.
Retrieves the pull request diff through the GitHub API.
Sends the diff to Claude Haiku 4.5 through Amazon Bedrock.
Receives a structured security review.
Posts the review as a comment on the pull request.

This is deliberately more than a model invocation wrapped in a Lambda function. The project includes webhook authentication, encrypted secret storage, infrastructure as code, restricted permissions, structured prompt design, external API integration, logging, and deployment automation.

How the AI Pull Request Security Reviewer Works

Diffender operates as a serverless code review bot built around an event-driven workflow. When a pull request changes, GitHub sends a signed webhook to Amazon API Gateway. In turn, API Gateway invokes AWS Lambda.

The function verifies the request, retrieves the pull request diff through the GitHub API, sends the changed code to Claude Haiku 4.5 through Amazon Bedrock, and posts the generated security review back to the pull request. In addition, Systems Manager Parameter Store protects the required secrets, while CloudWatch Logs records execution and error details.

For a broader introduction to event-driven compute, see the AWS Lambda cheat sheet.

AWS Services Behind the Review Workflow

Diffender uses a small set of managed AWS services, with each service handling a specific part of the pull request review process.

1. Amazon API Gateway

Amazon API Gateway exposes the public HTTPS endpoint that receives webhook events from GitHub. Because it integrates directly with Lambda, Diffender does not need a separate web server.

However, invalid traffic can still reach the endpoint before the Lambda function rejects it through signature validation.

2. AWS Lambda

AWS Lambda runs the main Diffender workflow. It verifies the webhook, retrieves the pull request diff, invokes Amazon Bedrock, and posts the review back to GitHub.

Since pull request activity occurs only when developers open or update code changes, event-driven compute fits the workload better than a continuously running server. Currently, the complete review must finish within the function’s configured timeout.

3. Amazon Bedrock

Amazon Bedrock gives Diffender managed access to Claude Haiku 4.5 without requiring separate model-hosting infrastructure. The Lambda function sends the pull request diff to the model and receives a structured security review in return.

However, language-model output remains probabilistic, so the review may miss issues or include false positives.

4. AWS Systems Manager Parameter Store

AWS Systems Manager Parameter Store holds the GitHub token and webhook secret as encrypted SecureString parameters. As a result, Diffender keeps sensitive values outside the source code and SAM template.

The current version does not rotate these values automatically, so a production deployment would need a separate rotation process.

5. AWS Identity and Access Management

AWS Identity and Access Management controls the AWS actions available to the Lambda function. The execution role grants access to Parameter Store, AWS KMS, and Amazon Bedrock for the review workflow.

Nevertheless, a production version could narrow the Amazon Bedrock and AWS KMS resource scopes further.

6. Amazon CloudWatch Logs

Amazon CloudWatch Logs records Lambda execution details and application errors. During development, these logs helped trace Amazon Bedrock invocation failures, GitHub API permission errors, and unexpected exceptions.

In addition, a production deployment should set an appropriate retention period and avoid writing sensitive values to the logs.

7. AWS Serverless Application Model

Finally, AWS Serverless Application Model, or AWS SAM, defines and deploys the Lambda function, API Gateway route, IAM policies, environment variables, and stack outputs.

Keeping these resources in one template makes the infrastructure reproducible and easier to review alongside the application code. The deployment identity still needs permission to create and update the required AWS resources.

API Gateway exposes the HTTPS endpoint that invokes Lambda, while the SAM Api event creates the integration through infrastructure as code.

Using Amazon Bedrock for Security Analysis

Diffender needs a model that can read source-code changes, identify potential security problems, and explain each finding in a format that works inside a GitHub pull request. The project does not require custom model training, dedicated inference servers, or GPU infrastructure.

Amazon Bedrock provides managed access to foundation models through AWS APIs. Diffender invokes Claude Haiku 4.5 through the AWS SDK, while the Lambda execution role controls access to the model.

Readers who are new to the service can review the Amazon Bedrock overview before continuing with the model configuration.

Diffender uses Claude Haiku 4.5 because this workload benefits from fast, focused analysis rather than long-form reasoning. In addition, the Lambda function uses the Amazon Bedrock Converse API, which provides a message-based interface for sending the system prompt, pull request diff, and inference settings to the model.

Prerequisites

The build requires:

An AWS account
AWS CLI version 2
AWS SAM CLI
Docker running locally
Python 3.12
Git
A GitHub account
Permission to create IAM, Lambda, API Gateway, CloudFormation, and Systems Manager resources
Access to Claude Haiku 4.5 through Amazon Bedrock in us-east-1

The commands in this tutorial assume a macOS, Linux, or compatible shell environment.

Part 1: Configure AWS Access

For a personal lab, an IAM user with programmatic access and broad deployment permissions is a direct way to complete the project. Configure the AWS CLI with the access key, secret access key, default Region, and output format:

 aws configure

Use these values when prompted:

 AWS Access Key ID: YOUR_ACCESS_KEY
 AWS Secret Access Key: YOUR_SECRET_ACCESS_KEY
 Default region name: us-east-1
 Default output format: json

Next, verify the active AWS identity:

 aws sts get-caller-identity

A successful response should contain the AWS account ID and the ARN of the active identity.

For a portfolio lab, attaching AdministratorAccess temporarily can reduce setup friction. However, this tutorial does not recommend that approach for production environments. AWS recommends temporary credentials and federated access for human users, commonly through AWS IAM Identity Center, instead of long-lived IAM user access keys.

Part 2: Prepare Claude Haiku 4.5 in Amazon Bedrock

Current Amazon Bedrock documentation states that AWS enables foundation-model access by default. However, first-time users of Anthropic models may still need to submit use-case details before invocation.

To complete this step, select an Anthropic model in the Bedrock model catalog or playground.

In the AWS Management Console:

Open Amazon Bedrock in us-east-1.
Open the model catalog or model playground.
Select Claude Haiku 4.5.
Submit the Anthropic use-case details if prompted.
Run a short test message.

Next, verify programmatic invocation with the AWS CLI:

 aws bedrock-runtime converse
 --model-id "anthropic.claude-haiku-4-5-20251001-v1:0"
 --messages '[{"role":"user","content":[{"text":"Find the security issue: password = "admin123""}]}]'
 --region us-east-1

The response should contain a model-generated message and token-usage metadata.

The final application uses the following US geographical inference profile:

 us.anthropic.claude-haiku-4-5-20251001-v1:0

AWS documents this identifier as a supported geo-inference ID for Claude Haiku 4.5.

Part 3: Create the GitHub Repository and Token

Create a public GitHub repository named Diffender with:

A README.md
An MIT license
A Python .gitignore

Next, create a fine-grained personal access token restricted to the Diffender repository.

Grant these repository permissions:

Pull requests: Read and write
Issues: Read and write
Contents: Read-only

The current implementation retrieves the pull request through the pull requests endpoint and posts the final message through the issue-comments endpoint.

That distinction is easy to miss. GitHub pull requests are also issues internally, so creating a general conversation comment on a pull request uses:

 POST /repos/{owner}/{repo}/issues/{issue_number}/comments

GitHub requires pull request or contents read access to retrieve the pull request. In addition, GitHub evaluates fine-grained token permissions for each REST endpoint.

Copy the token beginning with:

github_pat_

Do not add it to the repository, a local configuration file, or the SAM template.

Part 4: Create the Project Structure

Clone the repository and create the application directories:

 git clone https://github.com/chescaasignacion/Diffender.git
 cd Diffender
 mkdir -p src test-samples
 touch src/requirements.txt

The project structure is:

 Diffender/
 ├── src/
 │ ├── app.py
 │ └── requirements.txt
 ├── test-samples/
 │ └── insecure_example.py
 ├── template.yaml
 ├── README.md
 ├── LICENSE
 └── .gitignore

AWS SAM Template

Create template.yaml:

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: Diffender - an AI security code reviewer for GitHub PRs, powered by Amazon Bedrock.
Parameters:
  BedrockModelId:
    Type: String
    Default: us.anthropic.claude-haiku-4-5-20251001-v1:0
Globals:
  Function:
    Timeout: 60
    MemorySize: 256
    Runtime: python3.12
Resources:
  DiffenderFunction:
    Type: AWS::Serverless::Function
    Properties:
      FunctionName: diffender
      Handler: app.lambda_handler
      CodeUri: src/

      Environment:
        Variables:
          BEDROCK_MODEL_ID: !Ref BedrockModelId
          GITHUB_TOKEN_PARAM: /diffender/github-token
          WEBHOOK_SECRET_PARAM: /diffender/webhook-secret

      Policies:
        - Version: '2012-10-17'
          Statement:
            - Effect: Allow
              Action:
                - ssm:GetParameter
              Resource:
                - !Sub arn:aws:ssm:${AWS::Region}:${AWS::AccountId}:parameter/diffender/*

        - Version: '2012-10-17'
          Statement:
            - Effect: Allow
              Action:
                - kms:Decrypt
              Resource: ''
              Condition:
                StringEquals:
                  kms:ViaService: !Sub ssm.${AWS::Region}.amazonaws.com

        - Version: '2012-10-17'
          Statement:
            - Effect: Allow
              Action:
                - bedrock:InvokeModel
              Resource: ''

      Events:
        Webhook:
          Type: Api
          Properties:
            Path: /webhook
            Method: post
Outputs:
  WebhookUrl:
    Value: !Sub https://${ServerlessRestApi}.execute-api.${AWS::Region}.amazonaws.com/Prod/webhook

The template defines one Lambda function and one API Gateway REST API route. It also creates the Lambda execution role from inline policy statements.

The function can perform three categories of AWS action:

Retrieve the Parameter Store values
Decrypt encrypted parameters through AWS KMS
Invoke Amazon Bedrock

The Amazon Bedrock and AWS KMS statements use wildcard resource values in this tutorial. Therefore, a production version should evaluate whether those resources can be narrowed based on the selected AWS KMS key, model, and inference-profile ARNs.

Lambda Handler

The complete Lambda handler is available in the <a href=”https://github.com/chescaasignacion/Diffender”>Diffender GitHub repository</a>. The following sections focus on the code that controls secret retrieval, signature validation, Amazon Bedrock invocation, and GitHub integration.

Retrieve Secrets from Parameter Store

ssm = boto3.client("ssm")
_cache = {}

def _get_param(name):
    if name not in _cache:
        _cache[name] = ssm.get_parameter(
            Name=name,
            WithDecryption=True,
        )["Parameter"]["Value"]

    return _cache[name]

The function retrieves each parameter only once per warm Lambda execution environment. Later invocations can reuse the cached value.

Validate the GitHub Signature

def verify_signature(raw_body, signature_header):
    if not signature_header:
        return False

    secret = _get_param(WEBHOOK_SECRET_PARAM).encode()

    expected = (
        "sha256="
        + hmac.new(
            secret,
            raw_body,
            hashlib.sha256
        ).hexdigest()
    )

    return hmac.compare_digest(
        expected,
        signature_header
    )

This function recalculates the HMAC-SHA-256 signature from the raw request body and compares it with the value supplied by GitHub.

Retrieve the Pull Request Diff

def get_pr_diff(owner, repo, number):
    url = (
        f"https://api.github.com/repos/"
        f"{owner}/{repo}/pulls/{number}"
    )

    return _github_request(
        "GET",
        url,
        accept="application/vnd.github.v3.diff",
    )

The GitHub API returns the code changes as a unified diff, which contains the lines added, removed, or modified by the pull request.

Invoke Claude Through Amazon Bedrock

The function limits the diff to 60,000 characters before sending it to the model. It also caps the response at 1,500 tokens.

Post the Review to GitHub

GitHub uses the Issues Comments API for general pull request conversation comments.

Requirements File

The tutorial does not install an external application package. The Python Lambda runtime includes the AWS SDK for Python, so src/requirements.txt can remain empty for this build.

For a controlled production release, package and pin the required SDK version so the application does not depend on whichever SDK version the runtime includes.

Deliberately Insecure Test File

Create test-samples/insecure_example.py:

This intentionally unsafe file belongs only in an isolated demonstration repository. Therefore, never use it in an actual application.

Part 5: Build and Deploy with AWS SAM

AWS SAM keeps the application code and infrastructure definition in the same project. Readers who need a refresher on SAM templates, resources, and deployment commands can review the AWS SAM cheat sheet.

Build the application in a Python 3.12-compatible container:

The sam build command prepares the source and infrastructure definition for deployment. In addition, using a container reduces differences between the local machine and the Lambda build environment.

Next, deploy the stack:

Use the following guided responses:

During deployment, SAM displays an authorization warning because the endpoint does not use an API Gateway authorizer. That is intentional because GitHub cannot authenticate through IAM or Amazon Cognito before sending the webhook.

Instead, Diffender verifies each request through application-level HMAC validation.

After deployment, copy the WebhookUrl from the CloudFormation outputs:

Finally, commit samconfig.toml only after confirming that it contains no secrets. The file normally stores deployment preferences and parameter values, but secrets should remain in Parameter Store.

Part 6: Store Secrets in Parameter Store

Store the GitHub token as a SecureString parameter:


Next, generate and store a random webhook secret:

Retrieve the webhook secret once so it can be added to GitHub:

Parameter Store supports encrypted SecureString parameters backed by AWS KMS. The Lambda function requests decryption only when it retrieves the values.

Show only the parameter names in the screenshot. Never display the decrypted values.

After the first retrieval, the function caches both parameters in the Lambda execution environment. As a result, a warm invocation can reuse the values and avoid making two additional Parameter Store calls.

However, a warm environment may continue using a cached value after a token or webhook secret changes. Therefore, a production rotation process should account for that behavior.

Part 7: Configure the GitHub Webhook

In the Diffender repository:

Open Settings.
Select Webhooks.
Choose Add webhook.
Paste the API Gateway output into Payload URL.
Select application/json as the content type.
Paste the webhook secret.
Select Let me select individual events.
Enable Pull requests.
Save the webhook.

After the repository creates the webhook, GitHub sends a ping event. Diffender handles this event before attempting to parse a pull request:

Next, open the webhook delivery record and confirm that GitHub received HTTP status 200.

The webhook must use the exact API Gateway URL, including /Prod/webhook, and the secret must match the value stored in Parameter Store. In addition, the application/json content type ensures that Lambda receives the request body in the format expected by the signature-validation and JSON-parsing logic.

A successful ping confirms that GitHub can reach the endpoint and that the basic webhook configuration works. If the delivery fails, review the response in Recent Deliveries, correct the URL or secret, and select Redeliver.

Why a Public Endpoint Is Acceptable Here

GitHub must be able to reach the webhook over HTTPS, so the API Gateway endpoint remains publicly accessible. However, Diffender does not trust a request simply because it reaches that endpoint.

When the repository uses a webhook secret, GitHub adds an X-Hub-Signature-256 header containing an HMAC-SHA-256 signature of the request body. Diffender recalculates the signature using the same secret stored in Parameter Store:

The function then compares the calculated signature with the value sent by GitHub:

Using hmac.compare_digest helps reduce timing differences that can occur with a normal string comparison. Diffender rejects requests with missing or invalid signatures before it processes the pull request.

As a result, Diffender confirms that the sender knows the shared webhook secret. However, this control does not prevent unwanted traffic from reaching API Gateway. Therefore, a production deployment may also use throttling, AWS WAF, CloudWatch alarms, and cost monitoring.

Part 8: Test the AI GitHub Code Reviewer

Create a separate feature branch so the intentionally insecure sample does not affect the repository’s default branch:

Next, add the sample file, commit the change, and push the branch to GitHub:

Open a pull request from test/diffender-security-review into the default branch. GitHub then sends a pull request webhook with the opened action to the API Gateway endpoint.

After validating the webhook, Diffender retrieves the pull request diff, which contains the lines added or changed in the branch. The Lambda function then sends this code to Claude Haiku 4.5 through Amazon Bedrock for security analysis.

The sample intentionally includes several issues that should trigger findings:

A hardcoded AWS-style secret
SQL injection caused by unsafe string formatting
Command injection caused by shell=True
The use of MD5 for password hashing

At this point, GitHub push protection may detect the AWS-style key and block the push.

Although this may interrupt the demonstration, the behavior is expected and shows defense in depth. GitHub secret scanning focuses on exposed credentials, while Diffender reviews the rest of the code for issues such as injection vulnerabilities and weak cryptography.

If push protection blocks the test, use an obviously fake secret pattern or follow GitHub’s safe testing guidance. Never bypass push protection for a real credential.

After Diffender processes the webhook, it posts a review comment containing an overall risk level, a findings table, and recommended fixes.

How the Lambda Function Processes Code Changes

The Lambda handler processes each webhook in a controlled sequence. This order allows Diffender to reject invalid requests early and avoid unnecessary GitHub API calls or model invocations.

Validate the Incoming Request

First, the function reads the raw API Gateway request body and converts all HTTP header names to lowercase. This step allows the handler to locate GitHub headers consistently.

Next, Diffender validates the X-Hub-Signature-256 header by using the webhook secret from Parameter Store. If the request contains a missing or invalid signature, the function immediately returns an HTTP 401 response.

The handler then checks the GitHub event type. It responds to ping events with HTTP 200, ignores events unrelated to pull requests, and processes only the opened, reopened, and synchronize actions.

Retrieve and Analyze the Code Changes

After Diffender accepts the event, the handler reads the repository owner, repository name, and pull request number from the payload.

Next, the function calls the GitHub Pull Requests API and retrieves the diff containing the lines added or modified in the branch. It limits the diff to 60,000 characters to control model input size, response time, and cost.

The function then sends the prepared diff and security-review instructions to Claude Haiku 4.5 through the Amazon Bedrock Converse API.

Publish the Review and Handle Errors

After Claude returns the analysis, Diffender adds a short attribution footer and posts the findings through the GitHub Issues Comments API.

If a GitHub API request fails, the function records the status code and response body in CloudWatch Logs. Likewise, it logs unexpected exceptions before returning an appropriate HTTP status code to GitHub.

The order matters because Diffender validates each request before it reads the pull request details, calls GitHub, or invokes Amazon Bedrock. As a result, an unauthenticated request cannot trigger a security review or consume model resources.

Designing the Prompt for a Useful Security Review

The prompt does more than tell Claude to inspect a pull request. It sets the boundaries of the review, limits unsupported assumptions, and gives the response a format that works well inside GitHub.

Keep the Review Focused

Diffender looks specifically for security issues rather than acting as a general code reviewer. As a result, the review leaves out comments about naming, formatting, or code style that could distract from the actual security findings.

Base Findings on the Diff

The prompt also tells the model:

A pull request diff rarely contains the full application context. Without this instruction, the model might make assumptions about how a function works or whether a value contains sensitive information.

Therefore, the wording encourages Claude to connect each finding to code that appears in the pull request. It does not remove the possibility of false positives, but it makes the expected standard clear.

Make the Review Easy to Read

Diffender asks Claude to return an overall risk level, a findings table, and a collapsible section for each issue. Each finding should also explain why the issue matters and suggest a possible fix.

This format works well in a pull request because developers can scan the summary quickly and open the details when needed. Moreover, the consistent structure could later support GitHub Checks, labels, or merge rules.

A future version could request JSON instead of Markdown, validate the response against a schema, and render the GitHub comment separately.

Keep the Output Consistent

The Amazon Bedrock request uses a low temperature:

For this type of review, consistency provides more value than creative variation. Therefore, the lower value helps reduce unnecessary differences when Diffender analyzes similar code changes.

However, a language model still generates the response, so results may change slightly between runs or after a model update.

Put a Limit on Large Pull Requests

Diffender sends no more than 60,000 characters from the pull request diff:

This limit prevents a very large pull request from causing unexpected latency or token usage. Diffender measures the limit in characters rather than model tokens, so it serves as a practical safeguard rather than an exact token boundary.

However, the character limit may cut a long diff in the middle of a file. A more complete version could split the diff by file, review each section separately, combine repeated findings, and identify any files that it did not analyze.

Security Review of Diffender Itself

A security review tool should meet the same standard it applies to other code. Therefore, Diffender separates webhook validation, credential storage, model access, and review output into distinct controls.

Key safeguards include:

Diffender verifies each webhook request with HMAC-SHA-256.
The function compares signatures with hmac.compare_digest.
Systems Manager Parameter Store stores the GitHub token and webhook secret as encrypted SecureString parameters.
The fine-grained GitHub token grants access only to the Diffender repository.
The Lambda execution role grants only the AWS actions required by the workflow, although the resource scopes can be tightened further.
Diffender sends Claude only the pull request diff.
Claude cannot run commands, modify files, or merge code.
Diffender posts the findings as comments for human review.
The Lambda function writes errors to CloudWatch Logs for troubleshooting.

Together, these controls keep the model in an advisory role while GitHub and AWS permissions enforce access and execution boundaries.

What Would Change for Production

Although Diffender works well as a portfolio project, an organization-wide deployment would require several improvements.

Replace the personal access token with a GitHub App. GitHub Apps provide installation-scoped access and short-lived tokens, making them better suited to multiple repositories and teams.
Move review processing behind Amazon SQS. The webhook could validate the request, enqueue the event, and return immediately. A separate Lambda function could then perform the review.
Add idempotency with DynamoDB. Recording GitHub delivery IDs or commit SHAs would prevent webhook retries from creating duplicate comments.
Publish or update a single GitHub Check. This approach would avoid adding a new comment whenever a pull request receives another commit. In addition, it could later support merge controls.
Validate structured model output. Requesting JSON and validating it against a schema would provide more control over severity levels, required fields, and Markdown rendering.
Treat pull request content as untrusted input. The application should clearly separate the diff from the system instructions so comments or strings inside the code cannot redefine the model’s task.

Finally, a production deployment should configure API throttling, CloudWatch log retention, alarms, cost monitoring, and a process for rotating credentials.

Cost Considerations

Diffender uses consumption-based AWS services, so costs should remain low for a repository with occasional pull request activity.

AWS charges for Lambda and API Gateway according to usage, while standard Parameter Store parameters normally add no separate storage charge. Amazon Bedrock will likely account for the main variable cost because pricing depends on the input and output tokens processed by Claude Haiku 4.5.

To keep each review predictable, Diffender limits the pull request diff to 60,000 characters and caps the model response at 1,500 tokens. However, actual costs will still vary based on pull request size, model pricing, log volume, and AWS account eligibility.

Note: Check the current AWS pricing pages before publishing a fixed per-review estimate.

Current Limitations

Diffender supports security review rather than replacing it. Static analysis, dependency scanning, secret detection, penetration testing, and human judgment still provide coverage that a language model cannot guarantee.

More importantly, the model reviews only the code included in the pull request diff. It does not see the full call graph, deployment environment, runtime behavior, or surrounding business logic.

As a result, it may miss a vulnerability that depends on context outside the change. Conversely, it may flag code that appears risky in the diff but is safe within the wider application.

The current version also has several practical limits:

Diffender truncates pull request diffs after 60,000 characters.
Claude returns findings as Markdown rather than schema-validated data.
Diffender processes each review synchronously, which can delay the webhook response.
GitHub webhook retries may create duplicate comments.
Each pull request update can generate another review comment.
Findings do not currently affect the pull request’s merge status.
The current implementation uses a repository-scoped personal access token.
Diffender does not correlate findings with dependency databases, scanner results, or runtime exposure.
Adversarial text inside a diff may attempt to influence the model.
The project does not yet include an evaluation dataset that measures false positives and missed findings.

Diffender is most useful alongside deterministic tools such as Semgrep, Checkov, tfsec, dependency scanners, and GitHub secret scanning. These tools identify known rule violations, while Diffender adds context by explaining why a finding matters and how developers could address it.

Another example of AI-assisted security review is covered in Improving Application Security with AWS Security Agent.

Clean Up the Resources

When testing is complete, remove the AWS and GitHub resources that are no longer needed.

First, delete the AWS SAM stack:

Because the setup created the GitHub token and webhook secret manually, deleting the CloudFormation stack does not remove them. Therefore, delete both parameters separately:

Finally, delete the repository webhook and revoke the fine-grained GitHub personal access token if they will no longer be used.

After cleanup, confirm that CloudFormation deleted the stack successfully. In addition, check for resources outside the stack, particularly retained CloudWatch log groups, and remove them when they are no longer required.

What Diffender Demonstrates

Diffender brings together several skills that are difficult to show through certification study alone. The project covers the design of an event-driven AWS workload, secure webhook integration, request-signature validation, encrypted secret storage, restricted IAM permissions, infrastructure as code, and troubleshooting through CloudWatch Logs.

In addition, it demonstrates how a Lambda function can coordinate multiple services and external APIs. Diffender retrieves pull request data from GitHub, invokes Claude Haiku 4.5 through an Amazon Bedrock inference profile, and returns the result through GitHub’s Issues Comments API.

The most important part of the project is not simply that a language model reviews code. Instead, the model operates inside a controlled workflow with authenticated requests, limited context, restricted permissions, visible output, and human oversight.

The design also makes its current tradeoffs clear and provides a practical path from a working prototype to a more production-ready system.

Lessons from Building Diffender

Diffender began as a practical attempt to give every pull request an immediate security-focused review without adding another server to maintain.

The current version completes that workflow. It verifies GitHub webhooks, retrieves the changed code, sends the diff to Claude through Amazon Bedrock, and posts the findings back to the pull request.

However, building the project also highlighted the less visible parts of the system that matter just as much as the model. These include permissions, secret handling, API behavior, error handling, and operational limits.

There is still work to do before Diffender would be ready for a wider production rollout. GitHub App authentication, asynchronous processing, idempotency, and structured model output are the clearest next steps. These limitations are part of the project and provide a practical direction for future improvements.

Diffender is not intended to replace security engineers or established scanning tools. Instead, it shows how AI can support an existing review process while remaining behind clear security boundaries, controlled permissions, and human oversight.

The most useful outcome was not simply getting a model to comment on a pull request. It was learning what had to be built around the model for that comment to become a meaningful part of the review process.

Repository:

https://github.com/chescaasignacion/Diffender

References

Amazon Bedrock

Amazon Bedrock Converse API Reference

https://docs.aws.amazon.com/bedrock/latest/APIReference/API_runtime_Converse.html

Using the Converse API

https://docs.aws.amazon.com/bedrock/latest/userguide/conversation-inference.html

Claude Haiku 4.5 Model Card

https://docs.aws.amazon.com/bedrock/latest/userguide/model-card-anthropic-claude-haiku-4-5.html

Request Access to Amazon Bedrock Models

https://docs.aws.amazon.com/bedrock/latest/userguide/model-access.html

Simplified Model Access in Amazon Bedrock

https://aws.amazon.com/blogs/security/simplified-amazon-bedrock-model-access/

Using an Inference Profile for Model Invocation

https://docs.aws.amazon.com/bedrock/latest/userguide/inference-profiles-use.html

Cross-Region Inference in Amazon Bedrock

https://docs.aws.amazon.com/bedrock/latest/userguide/cross-region-inference.html

Supported Regions and Models for Inference Profiles

https://docs.aws.amazon.com/bedrock/latest/userguide/inference-profiles-support.html

Amazon Bedrock Pricing

https://aws.amazon.com/bedrock/pricing/

AWS Serverless and Security Services

Amazon API Gateway Integration with AWS Lambda

https://docs.aws.amazon.com/lambda/latest/dg/services-apigateway.html

AWS Lambda Execution Roles

https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html

AWS Lambda Pricing

https://aws.amazon.com/lambda/pricing/

Amazon API Gateway Pricing

https://aws.amazon.com/api-gateway/pricing/

AWS Systems Manager Parameter Store

https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html

AWS KMS Encryption for Parameter Store SecureString Parameters

https://docs.aws.amazon.com/systems-manager/latest/userguide/secure-string-parameter-kms-encryption.html

Creating Parameter Store Parameters with the AWS CLI

https://docs.aws.amazon.com/systems-manager/latest/userguide/param-create-cli.html

AWS Serverless Application Model Developer Guide

https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/what-is-sam.html

Building Applications with AWS SAM

https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-cli-command-reference-sam-build.html

Deploying Applications with AWS SAM

https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-deploying.html

Viewing AWS SAM Application Logs

https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-cli-command-reference-sam-logs.html

AWS IAM Security Best Practices

https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html

GitHub

Validating Webhook Deliveries

https://docs.github.com/en/webhooks/using-webhooks/validating-webhook-deliveries

Webhook Events and Payloads

https://docs.github.com/en/webhooks/webhook-events-and-payloads

GitHub REST API for Pull Requests

https://docs.github.com/en/rest/pulls/pulls

GitHub REST API for Issue Comments

https://docs.github.com/en/rest/issues/comments

Permissions Required for Fine-Grained Personal Access Tokens

https://docs.github.com/en/rest/authentication/permissions-required-for-fine-grained-personal-access-tokens

Managing Fine-Grained Personal Access Tokens

https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens

Push Protection for Repositories and Organizations

https://docs.github.com/en/code-security/secret-scanning/introduction/about-push-protection

Written by: Franchesca Asignacion

Franchesca Asignacion is a Cloud Business Development Manager at Tutorials Dojo. In addition to her business role, she works on the technical side of cloud and AI technologies, particularly in DevSecMLOps. She also produces educational video courses and writes technical articles focused on cloud computing and artificial intelligence, helping learners understand modern technologies and their practical applications.

Building Diffender: A Serverless AI Security Reviewer for GitHub Pull Requests with Amazon Bedrock