API categories

Categories

Findings

Findings are the results of the Plerion Detection Engine (PDE) Detection reporting a finding and rating the severity of the finding as it relates to best practices or a relevant compliance standard. Plerion Findings enable customers to reduce the risk to their environments by continuously highlighting areas for improvement. Explore findings APIs

Vulnerabilities

Vulnerabilities are known CVEs Plerion detects in the operating systems, packages and container images running in your cloud workloads. Each one carries the affected package and version, its severity, and whether a public exploit or a known-exploited-vulnerability record exists, so remediation can be ordered by real exposure rather than by CVSS score alone. Vulnerability exemptions record a CVE you have accepted or judged not applicable for a profile, with a reason, so it stops surfacing on later scans. Explore vulnerabilities APIs

Profiles

A profile holds the detection configuration Plerion applies to a set of integrations: which detections run, at what severity, and the exemptions that stop them reporting. Every tenant has a default profile covering the integrations that have not been given one of their own. Explore profiles APIs

Detection exemptions

A detection exemption stops one detection reporting findings against the assets it matches, so an accepted risk or a confirmed false positive stays closed. Match on the asset’s name, its tags, or its region, on the principal for Cloud Detection and Response (CDR) detections, or on the API Gateway routes you have accepted. Exemptions apply to the findings Plerion has already stored, not only to the next scan. An exemption is part of a detection’s configuration inside a profile, not a record of its own. There is no exemption ID and no endpoint for a single entry, so the unit of operation is the whole exemption set for one detection: read it, change it, and write all of it back. There are five exemption types. The type field decides which other fields apply.

Type	Exempts	Fields
`NAME_EXEMPTION`	Assets whose name matches	`condition`, `value`
`TAG_EXEMPTION`	Assets carrying a matching tag	`tagKey`, `tagValue`
`REGION_EXEMPTION`	Assets in the listed regions	`regions`
`PRINCIPAL_EXEMPTION`	Findings raised against a matching principal	`condition`, `value`
`ROUTE_EXEMPTION`	One API Gateway route	`apiId`, `routeKey`

Not every detection accepts exemptions, and of the ones that do, none accepts every type, so read the detection first. supportsExemptions and supportedExemptionTypes report what it takes, and a write using anything else is rejected rather than stored where it would never take effect. CDR detections report an actor rather than a misconfigured asset, so those that accept exemptions take PRINCIPAL_EXEMPTION only. PLERION-AWS-530 and PLERION-AWS-564 report a set of failing API Gateway routes, so they also take ROUTE_EXEMPTION. Where a detection accepts none, as those reporting external access grants do, close findings by recording a trusted principal on the profile instead. The read reports stored exemptions verbatim and the write accepts the same shape, so you can send a read’s response straight into a write. Entries created in the Plerion platform may carry no reason, which is why it is optional. Set one on the entries you add.

Quick start

Follow the guide to replace a detection’s exemptions using curl. Note: Replace {$PLERION_API_KEY} with your API key.

1. List your profiles

A profile applies to a set of integrations, and the exemption endpoints take its ID. You can pass default in place of an ID to address the tenant’s default profile, but the default profile covers only the integrations that have not been given a profile of their own. On a tenant with more than one profile, a write against default returns 200 and leaves every integration covered by another profile still reporting the finding. Read the integrations array on each profile, then write to each profile that covers the accounts you mean to change.

  export PLERION_API_URL=au.api.plerion.com
  export PLERION_API_KEY={$PLERION_API_KEY}
  curl "https://$PLERION_API_URL/v1/tenant/profiles" -H "Authorization: Bearer $PLERION_API_KEY"

2. Read the current exemption set

Take the detection ID from a finding’s detectionId field. Keep the version: it is how the write below detects a concurrent change. Treat it as an opaque string and pass it back unchanged, rather than parsing or comparing it, because its format can change. It is null when the detection has never been configured on the profile.

  export PLERION_PROFILE_ID=default
  export PLERION_DETECTION_ID=PLERION-AWS-16
  export PLERION_EXEMPTIONS_URL="https://$PLERION_API_URL/v1/tenant/profiles/$PLERION_PROFILE_ID/detection-settings/$PLERION_DETECTION_ID/exemptions"
  # Capture the version to send back in step 3. `// empty` leaves the variable
  # empty when version is null, rather than setting it to the string "null".
  export PLERION_EXEMPTIONS_VERSION=$(curl -s "$PLERION_EXEMPTIONS_URL" \
    -H "Authorization: Bearer $PLERION_API_KEY" | jq -r '.data.version // empty')

3. Write the whole set back

Send the exemptions you read plus your addition. Anything you leave out is removed, and an empty array clears the set. Pass the version as If-Match. Without that header the write applies unconditionally and overwrites a concurrent change with no 412, so omit it only when the version was null. Step 2 leaves the variable empty in that case, and curl sends no header for an empty value, so the same command works on a detection that has never been configured.

  curl -X PUT "$PLERION_EXEMPTIONS_URL" \
    -H "Authorization: Bearer $PLERION_API_KEY" \
    -H "Content-Type: application/json" \
    -H "If-Match: $PLERION_EXEMPTIONS_VERSION" \
    -d '{
      "exemptions": [
        {
          "type": "NAME_EXEMPTION",
          "reason": "ACCEPTED_RISK",
          "condition": "starts-with",
          "value": "acme-sandbox-"
        },
        {
          "type": "TAG_EXEMPTION",
          "reason": "COMPENSATING_CONTROL",
          "tagKey": { "option": "equals", "value": "environment" },
          "tagValue": { "option": "equals", "value": "test" }
        }
      ]
    }'

A 412 means the detection’s configuration changed after the version you supplied. That covers a change to its exemptions, and also a change to its severity or parameters, including one made by saving the profile in the Plerion platform. Read the exemptions again, reapply your change to what comes back, and write once more. Explore detection exemptions APIs

Assets

Plerion Assets form the basis upon which all Plerion contextual security is reported. Every unique cloud resource on which Plerion collects information is classified as a single asset on the Plerion platform. A detailed asset view combines various sources of security, compliance, and risk-related metrics to empower customers to make high-impact decisions when evaluating a single asset in relation to their overall cloud environments. Explore assets APIs

Asset groups

Asset Group is classifying assets into specific group based on the different criteria such as integration, asset tag, resource type and resource name. This helps users to manage, organize, and analyze their assets more efficiently. User can group assets based on the teams, projects, business units, environments, tech stack etc. Explore asset groups APIs

Alerts

The Plerion Risk Score (PRS) Engine has calculated Alerts that are the highest priority items based on the available information across Identity, Configuration, and Vulnerability Management. Alerts offer the highest value CONTEXT from across the Plerion Platform. Alerts are accompanied by a narrative to guide customers on the overall risk and the recommended remediation steps to take to improve, reduce, or eradicate the identified risk. Explore alerts APIs

Integrations

Integrations enable customers to connect their own cloud environments to the Plerion platform. Integrations allow for the collection of data from the integrated environment, e.g. Connecting Plerion to your cloud service provider will facilitate Plerion to collect, analyze, and prioritize the most significant risks across your cloud operating environments. Explore integrations APIs

Tenant

The Plerion platform caters for multi-tenancy. Multi-tenancy within the Plerion platform delivers isolation for the integrations supported by Plerion. Each Tenancy (Tenant) allows for multiple inbound or outbound integrations, like integrating with Cloud Service Providers (AWS, Azure, GCP), and their corresponding Audit log service (AWS: CloudTrail, Azure: AuditLog, GCP: Cloud Audit Log). Explore tenant APIs

Risks

In a cloud environment there are usually many hundreds or thousands of misconfigurations, but which of those pose a clear and present danger of a breach? That’s what the Plerion risk is about. Explore risks APIs

AWS integration

In order to connect your AWS account to Plerion or update existing account, you will need,

CloudFormation Template URL. Retrieve the template from Get CloudFormation template
External Id of the tenant. Retrieve the External Id from Get the external id of the tenant
Plerion AWS Account Id. The value will always be 588158338731
Tenant Id. Identifies your tenant when the stack registers itself with Plerion. Retrieve the tenant Id from Get tenant details
Plerion API URL. The host used by the API calls above. The value will always be au.api.plerion.com
Select Capabilities. Select CSPM for CSPM only capability or ALL for both CSPM and CWPP capability.
Select KMSKeyAccessMode. When CWPP is enabled, you can choose the KMS Key access mode to facilitate Plerion’s access to keys for decrypting volumes, images, and lambda code. In the ALL_KEYS mode, Plerion is granted access to all KMS keys in the account. However, you have the option to restrict access to certain keys by applying the “PlerionAccess: Denied” tag. Alternatively, the SELECTED_KEYS mode allows Plerion access solely to the KMS keys that have been tagged with “PlerionAccess: Granted”.

Passing the parameters to the CloudFormation template will create a new AWS integration or update existing integration.

Quick start

Follow the guide to create a new AWS integration or update existing integration using curl command. Note: Replace {$PLERION_API_KEY} with your API key.

Create a new AWS integration

  export PLERION_API_URL=au.api.plerion.com
  export PLERION_API_KEY={$PLERION_API_KEY}
  export PLERION_AWS_ACCOUNT_ID=588158338731
  # Fetch the template URL
  export TEMPLATE_URL=$(curl -s GET  "https://$PLERION_API_URL/v1/tenant/cloudformation-templates?type=AWSAccount" -H "Authorization: Bearer $PLERION_API_KEY" | jq -r '.data.templateURL')
  # Fetch the external ID
  export EXTERNAL_ID=$(curl -s -X GET  "https://$PLERION_API_URL/v1/tenant/external-id" -H "Authorization: Bearer $PLERION_API_KEY" | jq -r '.data.externalId')
  # Fetch the tenant ID
  export TENANT_ID=$(curl -s -X GET  "https://$PLERION_API_URL/v1/tenant" -H "Authorization: Bearer $PLERION_API_KEY" | jq -r '.data.tenantId')
  # Create the stack
  export PLERION_STACK_NAME=plerion-aws-integration
  aws cloudformation create-stack --stack-name $PLERION_STACK_NAME --template-url $TEMPLATE_URL --capabilities CAPABILITY_NAMED_IAM \
    --parameters ParameterKey=ExternalId,ParameterValue=$EXTERNAL_ID \
      ParameterKey=PlerionAccountId,ParameterValue=$PLERION_AWS_ACCOUNT_ID  \
      ParameterKey=TenantId,ParameterValue=$TENANT_ID \
      ParameterKey=Capabilities,ParameterValue=ALL \
      ParameterKey=KMSKeyAccessMode,ParameterValue="ALL_KEYS"
  # Wait for the stack to complete
  aws cloudformation wait stack-create-complete --stack-name $PLERION_STACK_NAME

Update an existing AWS integration

  export PLERION_API_URL=au.api.plerion.com
  export PLERION_API_KEY={$PLERION_API_KEY}
  export PLERION_AWS_ACCOUNT_ID=588158338731
  # Fetch the template URL
  export TEMPLATE_URL=$(curl -s GET  "https://$PLERION_API_URL/v1/tenant/cloudformation-templates?type=AWSAccount" -H "Authorization: Bearer $PLERION_API_KEY" | jq -r '.data.templateURL')
  # Fetch the external ID
  export EXTERNAL_ID=$(curl -s -X GET  "https://$PLERION_API_URL/v1/tenant/external-id" -H "Authorization: Bearer $PLERION_API_KEY" | jq -r '.data.externalId')
  # Fetch the tenant ID
  export TENANT_ID=$(curl -s -X GET  "https://$PLERION_API_URL/v1/tenant" -H "Authorization: Bearer $PLERION_API_KEY" | jq -r '.data.tenantId')
  # Update an existing stack
  export PLERION_STACK_NAME=plerion-aws-integration
  aws cloudformation update-stack --stack-name $PLERION_STACK_NAME --template-url $TEMPLATE_URL --capabilities CAPABILITY_NAMED_IAM \
    --parameters ParameterKey=ExternalId,ParameterValue=$EXTERNAL_ID \
      ParameterKey=PlerionAccountId,ParameterValue=$PLERION_AWS_ACCOUNT_ID  \
      ParameterKey=TenantId,ParameterValue=$TENANT_ID \
      ParameterKey=Capabilities,ParameterValue=ALL \
      ParameterKey=KMSKeyAccessMode,ParameterValue="ALL_KEYS"
  # Wait for the stack to complete
  aws cloudformation wait stack-update-complete --stack-name $PLERION_STACK_NAME

Explore AWS integration APIs

Compliance frameworks

Compliance Frameworks help our customers meet their regulatory and compliance obligations, and reduce compliance risk, enabling them to achieve their strategic objectives. Plerion offers customers hundreds of prebuilt detections delivering continuous assurance against industry standards and best practices. Explore compliance frameworks APIs

Well-Architected frameworks

The AWS Well-Architected Framework helps customers design secure, high-performing, resilient, and efficient cloud infrastructure. Plerion continuously assesses your environment against the AWS Well-Architected pillars, aligning your architecture with AWS best practices and accelerating improvement. Explore Well-Architected frameworks APIs

Code security

Code security scans infrastructure-as-code before it reaches a cloud environment, so a misconfiguration is caught in the pull request rather than after deployment. Upload a Terraform, CloudFormation or Kubernetes archive to start a scan, then retrieve the findings it produced and any vulnerabilities detected in container images the templates reference. Explore code security APIs

Audit logs

Audit logs provide a comprehensive trail of user activities and system operations within a tenant. These logs capture important events such as user logins, API calls, configuration changes, and other security-relevant activities. Audit logs help with compliance, security monitoring, and troubleshooting. Explore audit logs APIs

AWS access grants

An access grant records the access that one of your AWS resources gives to a single principal. Plerion derives grants from resource policies, IAM role trust policies, AWS Resource Access Manager shares and cross-account share attributes, capturing the principal, the actions allowed and any conditions attached. Use these APIs to pull the inventory into your own audits or SIEM, and to record review decisions without signing in to Plerion. Explore AWS access grants APIs

Overview

API documentation

Categories

Findings

Vulnerabilities

Profiles

Detection exemptions

Quick start

1. List your profiles

2. Read the current exemption set

3. Write the whole set back

Assets

Asset groups

Alerts

Integrations

Tenant

Risks

AWS integration

Quick start

Create a new AWS integration

Update an existing AWS integration

Compliance frameworks

Well-Architected frameworks

Code security

Audit logs

AWS access grants

​Categories

​Findings

​Vulnerabilities

​Profiles

​Detection exemptions

​Quick start

1. List your profiles

2. Read the current exemption set

3. Write the whole set back

​Assets

​Asset groups

​Alerts

​Integrations

​Tenant

​Risks

​AWS integration

​Quick start

Create a new AWS integration

Update an existing AWS integration

​Compliance frameworks

​Well-Architected frameworks

​Code security

​Audit logs

​AWS access grants

Categories

Findings

Vulnerabilities

Profiles

Detection exemptions

Quick start

Assets

Asset groups

Alerts

Integrations

Tenant

Risks

AWS integration

Quick start

Compliance frameworks

Well-Architected frameworks

Code security

Audit logs

AWS access grants