asecurityteam/nexpose-scan-notifier repository overview

⁠We no longer use Nexpose.

This repository is not maintained.

⁠Nexpose Scan Notifier

https://github.com/asecurityteam/nexpose-scan-notifier⁠

• Nexpose Scan Notifier⁠
  • Overview⁠
  • Configuration⁠
    • Timestamp Storage⁠
      • DynamoDB⁠
      • Dependency Check⁠
  • Status⁠
  • Contributing⁠
    • Building And Testing⁠
    • Quality Gates⁠
    • License⁠
    • Contributing Agreement⁠

⁠Overview

Nexpose Scan Notifier is an API service which queries Nexpose and generates events for completed scans.

⁠Configuration

⁠Timestamp Storage

This project depends on a mechanism to persist and retrieve the timestamp of the last processed scan. This ensures that successfully processed scans are not reprocessed, and any scans which are not successfully produced can be retried.

The current implementation of the timestamp storage interface is a DynamoDB table.

⁠DynamoDB

This project stores the timestamp of the last processed scan in a simple DynamoDB table. The table uses a static partition key (which uses "lastProcessed" as its default value), and successfully processed timestamps are upserted with the key "timestamp". The table schema would look like the following:

{
    TableName : "ScanTimestamp",
    KeySchema: [
        {
            AttributeName: "partitionkey",
            KeyType: "HASH", //Partition key
        }
    ],
    AttributeDefinitions: [
        {
            AttributeName: "partitionkey",
            AttributeType: "S"
        }
    ]
}

⁠Dependency Check

Depending on the user, this service or app can be composed of a bunch of sidecars. While one can check whether the configuration and placement of these sidecars are configured correctly internally it might be useful to check whether environment variables point to the correct external dependencies.

An obvious external dependency would be Nexpose itself. If the Dynamo DB and Nexpose environment variables are configured within docker-compose.yaml, then users can check whether they are able to connect to with these dependencies with /dependencycheck(example in gateway-incoming.yaml).

⁠Status

This project is in incubation which means we are not yet operating this tool in production and the interfaces are subject to change.

⁠Contributing

⁠Building And Testing

We publish a docker image called SDCLI⁠ that bundles all of our build dependencies. It is used by the included Makefile to help make building and testing a bit easier. The following actions are available through the Makefile:

• make dep

  Install the project dependencies into a vendor directory

• make lint

  Run our static analysis suite

• make test

  Run unit tests and generate a coverage artifact

• make integration

  Run integration tests and generate a coverage artifact

• make coverage

  Report the combined coverage for unit and integration tests

• make build

  Generate a local build of the project (if applicable)

• make run

  Run a local instance of the project (if applicable)

• make doc

  Generate the project code documentation and make it viewable locally.

⁠Quality Gates

Our build process will run the following checks before going green:

• make lint
• make test
• make integration
• make coverage (combined result must be 85% or above for the project)

Running these locally, will give early indicators of pass/fail.

⁠License

This project is licensed under Apache 2.0. See LICENSE.txt for details.

⁠Contributing Agreement

Atlassian requires signing a contributor's agreement before we can accept a patch. If you are an individual you can fill out the individual CLA⁠. If you are contributing on behalf of your company then please fill out the corporate CLA⁠.