Appknox

Azure Extension for Appknox Automated Scanning

This extension adds the ability to perform automated app security testing for Android and iOS mobile apps through the Appknox Platform.

Task Parameters

Following are parameters needed for the task:

Installation

Add Appknox Task to your Azure Pipeline

1. From Azure Pipelines Edit page Search for the Appknox task in the Tasks tab.

   

2. Configured the required params.

   

   

3. Pick Authentication Type -- Access Token or Service Account -- to show the matching credential field(s). $(appknoxtoken) is a build variable with its lock enabled on the Variables tab. Use accessToken for a Personal Access Token, or accessKeyId + accessKeySecret for a Service Account (created by an organization owner or admin from the Appknox dashboard) -- provide exactly one of the two.

   

   For more information about Variables

4. [Optional] Using Proxy: Appknox task requests can be routed via a web proxy server, which can be configured in environmental variable HTTP_PROXY or HTTPS_PROXY in the format http(s)://username:password@hostname:port. It fallbacks to azure pipeline agent's proxy if not set.

View Output logs

The above task will upload the binary which will initiate Appknox automated scanning. The progress can be viewed in the pipeline build logs.

When KnoxIQ triage is enabled (triggerKnoxiq, or automatically when thresholdType is exploitLikelihood), it runs (Started → In progress → Completed) before the gate is evaluated, so each finding is checked against the configured gate using its real-world exploit likelihood rather than raw CVSS severity. Findings KnoxIQ couldn't triage (exploit likelihood "Unknown") are flagged as "needs review" and excluded from the build decision — full details are available on the Appknox dashboard.

Example — build fails: the gate is exploit likelihood >= Low, and 20 findings meet or exceed it, so the build fails. One additional finding is "needs review" and does not affect the outcome either way.

Example — build passes: the gate is risk >= Critical, and the only finding is "needs review" (exploit likelihood "Unknown"), so it's excluded from the decision — nothing breaches the gate and the build passes.

Examples

Pipeline for Android

# Android
# Build your Android project with Gradle.
# Add steps that test, sign, and distribute the APK, save build artifacts, and more:
# https://docs.microsoft.com/azure/devops/pipelines/languages/android

trigger:
- master

pool:
  vmImage: 'macos-latest'

steps:
- task: Gradle@2
  inputs:
    workingDirectory: ''
    gradleWrapperFile: 'gradlew'
    gradleOptions: '-Xmx3072m'
    publishJUnitResults: false
    testResultsFiles: '**/TEST-*.xml'
    tasks: 'assembleDebug'

- task: appknox@2
  inputs:
    filepath: './app/build/outputs/apk/debug/app-debug.apk'
    accessToken: '$(appknoxtoken)'
    thresholdType: 'risk'
    riskThreshold: 'medium'
    host: 'https://secure.appknox.com/'

Using Health Score Threshold

- task: appknox@2
  inputs:
    filepath: './app/build/outputs/apk/debug/app-debug.apk'
    accessToken: '$(appknoxtoken)'
    thresholdType: 'healthScore'
    healthScoreThreshold: '70'
    host: 'https://secure.appknox.com/'

Note: thresholdType selects which threshold is enforced. Set it to risk and provide riskThreshold, healthScore and provide healthScoreThreshold, or exploitLikelihood and provide exploitLikelihoodThreshold.

Using a Service Account instead of an Access Token

- task: appknox@2
  inputs:
    filepath: './app/build/outputs/apk/debug/app-debug.apk'
    accessKeyId: '$(appknoxaccesskeyid)'
    accessKeySecret: '$(appknoxaccesskeysecret)'
    thresholdType: 'risk'
    riskThreshold: 'medium'
    host: 'https://secure.appknox.com/'

Note: Provide exactly one of accessToken or the accessKeyId/accessKeySecret pair. Providing only one of the pair, or neither, fails the task with a validation error before any scan is attempted. If both are set, authType decides which one is used (accessToken wins unless authType is serviceAccount).

Using Exploit Likelihood Threshold

- task: appknox@2
  inputs:
    filepath: './app/build/outputs/apk/debug/app-debug.apk'
    accessToken: '$(appknoxtoken)'
    thresholdType: 'exploitLikelihood'
    exploitLikelihoodThreshold: 'high'
    host: 'https://secure.appknox.com/'

Note: Exploit Likelihood gates on KnoxIQ's real-world exploitability assessment instead of raw CVSS risk. It requires KnoxIQ triage to complete for the uploaded file, so --knoxiq is always passed on upload when this threshold type is selected -- triggerKnoxiq is ignored in this mode regardless of its checkbox value (the classic designer UI does not grey it out, since Azure Pipelines tasks have no declarative way to disable one input based on another's value -- this is enforced in code, not the UI). If KnoxIQ triage is unavailable or does not complete in time, the task falls back to a risk check at LOW -- any Low-or-higher finding fails the build, regardless of which Exploit Likelihood level was configured. Check the pipeline logs for which gate actually ran.

Requesting KnoxIQ Triage

- task: appknox@2
  inputs:
    filepath: './app/build/outputs/apk/debug/app-debug.apk'
    accessToken: '$(appknoxtoken)'
    thresholdType: 'risk'
    riskThreshold: 'medium'
    host: 'https://secure.appknox.com/'
    triggerKnoxiq: true

Downloading a PDF Report

- task: appknox@2
  inputs:
    filepath: './app/build/outputs/apk/debug/app-debug.apk'
    accessToken: '$(appknoxtoken)'
    thresholdType: 'risk'
    riskThreshold: 'medium'
    host: 'https://secure.appknox.com/'
    generatePdfReport: true