# Pentesting with Software Secured

Use this guide to help you navigate the penetration testing (pentesting) process and how to use Portal to maximize your pentesting capabilities.

<figure><picture><source srcset="/files/gZ0DjiXp0jp759A19H6v" media="(prefers-color-scheme: dark)"><img src="/files/67ZjtppGW8wsxj3VmYjj" alt=""></picture><figcaption></figcaption></figure>

Welcome to this how-to guide for your penetration test—also known as a pentest—with <code class="expression">space.vars.company\_name</code>! By now, you've decided to get a pentest or other service from us, and we are looking forward to helping you improve your security and compliance across your products.&#x20;

## Penetration testing overview

When you begin a pentest with <code class="expression">space.vars.company\_name</code>, you get comprehensive and thorough testing from beginning to end.&#x20;

The testing process includes the following order of operations:

1. [Preparing your environment for the testing team](/planning/preparing-your-environment-for-the-testing-team).
2. Completing the [Pentest checklist](/checklist/pentest-checklist) (including the [Infrastructure summary](/checklist/infrastructure-summary)).
3. Participating in the [Kickoff call](/planning/kickoff-call).&#x20;
4. Monitoring progress [During the active pentest](/planning/during-the-active-pentest).&#x20;
5. [Viewing and acting on your pentest results](/findings/viewing-and-acting-on-your-pentest-results).&#x20;

Once your test is complete, you will have everything you need to start remediating any issues that were identified.

1. [Remediating vulnerabilities](/after-testing/remediating-vulnerabilities) and tracking your progress related to the [Service Level Agreements (SLAs)](/findings/service-level-agreements-slas).
2. [Retesting your vulnerabilities](/after-testing/retesting-your-vulnerabilities) after remediation.
3. Sending [Consultation requests](/after-testing/consultation-requests) to review complex issues.
4. [Viewing and downloading reports and executive summaries](/reports-and-certificates/viewing-and-downloading-reports-and-executive-summaries).&#x20;

## Portal overview

Use <code class="expression">space.vars.product\_name</code> during the pentest to stay on top of your test's schedule, tasks, and results all in one place. &#x20;

The following tasks are completed in <code class="expression">space.vars.product\_name</code> during your pentest:&#x20;

1. Completing [User management](/account/user-management) tasks and enabling any [Integrations](/account/integrations).
2. Filling out the [Pentest checklist](/checklist/pentest-checklist) (including the [Infrastructure summary](/checklist/infrastructure-summary)).
3. Reviewing the [Pentest start date and rescheduling](/planning/kickoff-call/pentest-start-date-and-rescheduling) as required.&#x20;
4. [Viewing and acting on your pentest results](/findings/viewing-and-acting-on-your-pentest-results).&#x20;
5. Tracking remediation with your issue-tracking integrations (such as [Jira](/account/integrations/jira)).&#x20;
6. Sending requests for [Retesting your vulnerabilities](/after-testing/retesting-your-vulnerabilities).&#x20;
7. Sending [Consultation requests](/after-testing/consultation-requests).&#x20;
8. [Viewing and downloading reports and executive summaries](/reports-and-certificates/viewing-and-downloading-reports-and-executive-summaries).&#x20;

Can't find the answer you are looking for? Send us an email at [<mark style="color:orange;">portal@softwaresecured.com</mark>](mailto:portal@softwaresecured.com).


# Glossary \<WIP>

Reference common terms and acronyms that are used in this guide.

### Executive Summary

A document that includes a summary of the report that can be shared with external customers and shareholders as proof of completion for the pentest.&#x20;

For more information, see [Viewing and downloading reports and executive summaries](/reports-and-certificates/viewing-and-downloading-reports-and-executive-summaries).&#x20;

***

### Component

A category to assign to specified findings during a pentest.&#x20;

For more information, see [Project components](/planning/kickoff-call/project-components).&#x20;

***

### Finding

A vulnerability discovered by <code class="expression">space.vars.company\_name</code> during a pentest. Each finding has its own unique identifier in the pentest report.&#x20;

***

### Intercepting Proxy

A tool that allows testers to intercept, inspect, modify, and send HTTP requests to a server in order to test for different vulnerabilities.&#x20;

***

### Pentest Director

The primary tester who will conduct your pentest. This tester will also be your main point of contact during the test if you have any questions. Other testers might be involved in your test depending on the scope, timeframe, and complexity.&#x20;

***

### Penetration Test

An authorized test that simulates real-world attacks on a product to determine the state of its security and compliance. Often abbreviated as *pentest*.

* For a more detailed definition, see [Penetration Testing | SANS Institute](https://www.sans.org/security-resources/glossary-of-terms/penetration-testing).&#x20;
* For <code class="expression">space.vars.company\_name</code>'s testing methodologies, see [Testing methodologies \<WIP>](/methodologies/testing-methodologies-less-than-wip-greater-than).&#x20;

***

### Production Environment

The live environment for a product that can be accessed externally by clients. Production environments are tested during network and infrastructure tests; production can be tested during other types of tests as well, but those tests have higher risks for outages and data deletion.&#x20;

For more information, see [Preparing your environment for the testing team](/planning/preparing-your-environment-for-the-testing-team).&#x20;

***

### Report

The results of the pentest that includes detailed information about <code class="expression">space.vars.company\_name</code>'s findings.&#x20;

For more information, see [Viewing and downloading reports and executive summaries](/reports-and-certificates/viewing-and-downloading-reports-and-executive-summaries).&#x20;

***

### Retest/retesting

A service where <code class="expression">space.vars.company\_name</code> retests vulnerabilities that we previously reported to see if you remediated them successfully.&#x20;

For more information, see [Retesting your vulnerabilities](/after-testing/retesting-your-vulnerabilities).&#x20;

***

### SLA

Service Level Agreement

For more information, see [Service Level Agreements (SLAs)](/findings/service-level-agreements-slas).&#x20;

***

### Staging/test environment

A non-production environment for a product that can only be accessed internally. These environments are typically where development is tested. In general, <code class="expression">space.vars.company\_name</code> tests these non-production environments to minimize risk for outages and data deletion on the production environment.&#x20;

For more information, see [Preparing your environment for the testing team](/planning/preparing-your-environment-for-the-testing-team).&#x20;

***

### Vulnerability

A flaw or weakness in a system or product that can be exploited by attackers. Sometimes used interchangeably with finding or issue.&#x20;


# What's new in Portal

We are constantly adding new features to Portal to improve your pentest experience.

## June 2026

### Azure DevOps integration

Integrate Azure DevOps with <code class="expression">space.vars.product\_name</code> to link vulnerabilities to your work items and track remediation progress. For more information, see [Azure DevOps](/account/integrations/azure-devops).

### GitHub integration

Integrate GitHub with <code class="expression">space.vars.product\_name</code> to help streamline project management by converting your vulnerabilities into GitHub issues. For more information, see [GitHub](/account/integrations/github). &#x20;

### Microsoft Teams integration

Integrate Microsoft Teams with <code class="expression">space.vars.product\_name</code> to receive <code class="expression">space.vars.product\_name</code> notifications in your Teams channel. For more information, see [Microsoft Teams](/account/integrations/microsoft-teams).&#x20;

### GRC tool integrations

Integrate your Governance, Risk and Compliance (GRC) tools with <code class="expression">space.vars.product\_name</code> to monitor and simplify GRC tracking for different security regulations. Currently, <code class="expression">space.vars.product\_name</code> supports integrations for Vanta and Drata. For more information, see [GRC tools (Vanta and Drata) \<WIP>](/account/integrations/grc-tools-vanta-and-drata-less-than-wip-greater-than).&#x20;


# Preparing your environment for the testing team

Preparing your testing environment and the differences between testing on staging versus production.

When preparing an environment for the penetration test, ensure that it mirrors your production environment as closely as possible and accurately represents normal operating conditions for a typical user or customer.&#x20;

***

### **Test environment requirements**

The following requirements help <code class="expression">space.vars.company\_name</code> ensure the best possible coverage of the test:&#x20;

* All features that are used for the most common use cases or workflows are fully enabled, configured, and licensed on the environment.
* All known differences between the test and production environment are highlighted during the kickoff call.&#x20;
* If the system has known integrations with other external systems, <code class="expression">space.vars.company\_name</code> might need access or testing equivalents of those to ensure that we can test for any risks posed by the integration points and any associated data flows into the system.
* If a web application firewall (WAF), intrusion prevention system (IPS), or other security appliance is in use, they either need to be disabled, or the IP addresses of the testers need to be given access permission through your network's allowlist (or whitelist).
  * <code class="expression">space.vars.company\_name</code>’s IP addresses are included in the pentest checklist. For more information, see [Pentest checklist](/checklist/pentest-checklist).&#x20;
* The test environment must be consistently available throughout the test dates until final report delivery. This access supports the report writing, evidence collection, and our quality assurance process. Once the report is delivered, the environment can be de-provisioned if needed.&#x20;
  * Alternatively, in packages with frequent pentesting operations like [Penetration Testing as a Service (PTaaS)](https://www.softwaresecured.com/service/penetration-testing-as-a-service), the environment is kept live to facilitate faster retesting and consultation requests.

These requirements help <code class="expression">space.vars.company\_name</code> ensure the best possible coverage of the test.&#x20;

{% hint style="info" %}
If you wish to test the effectiveness of these controls, ask us about other test offerings such as [red teaming](https://www.softwaresecured.com/service/red-teaming) and [cloud security reviews](https://www.softwaresecured.com/service/secure-cloud-review).&#x20;
{% endhint %}

***

### Testing the production environment

Any network or infrastructure pentests are conducted on the production environment.&#x20;

For all other test portions—such as application or software— <code class="expression">space.vars.company\_name</code>'s best practice is to test on a staging or a test environment.&#x20;

Pentesting an application in a production environment is possible; however, pentesting by design is an invasive process and tests come with risks for outages or data deletion. When focusing solely on the network, these risks are less of a concern compared to when data or availability can be compromised.&#x20;

{% hint style="warning" %}
When testing on production is required, complete a backup before the start of testing—and at regular intervals throughout the test—to ensure business continuity if any outages occur.
{% endhint %}

For more information about the advantages and disadvantages of testing on production, see [15 Risks & Rewards of Pentesting in a Production Environment](https://www.softwaresecured.com/post/pentesting-in-a-production-environment).


# Kickoff call

What to expect for your kickoff call and how to prepare for it.

As a part of the pentest checklist, <code class="expression">space.vars.company\_name</code> requests a kickoff call between the pentesting team and the customer's pentest primary owner.&#x20;

<code class="expression">space.vars.company\_name</code>'s best practice is to schedule this kickoff call 1-2 business days before the test start date, and no later than within the first few hours of the first day of testing.&#x20;

This call gives you time to ask questions and provide information to the testing team, including:&#x20;

* the pentest checklist
* any specific requirements your team has for reporting
* project components, and
* an application or product demo.&#x20;

***

### Pentest Primary Owner

If multiple people are involved in the test, designate a primary point of contact in your organization to whom all communications will be addressed and channeled during testing. The Pentest Manager will reach out to confirm who the primary contact is.&#x20;

To keep communication optimal and the test on track, the primary contact will take ownership of the communication on behalf of your team.&#x20;

***

### Project Components

If your project contains large assets that can be split into separate logical components, we will ask you about this option in the kickoff call. These components help organize the tests findings by associating them with one or more components in the project, which can greatly simplify any separation concerns and reporting requirements that might occur after your pentest is complete.

{% hint style="info" %}
For more information on how Project Components can simplify your vulnerability management, please see [Project components](/planning/kickoff-call/project-components)
{% endhint %}

***

### Application Demo

During the call, we will ask for a demo of the application that includes the following information:

* Provide a general technical overview.
* Demonstrate the top 4-5 use cases; perform these demos in the specific environment that is provided for testing, if possible.
* Validate that the application and environment is fully accessible, functional, and configured before the start of the test; identify any gaps to prevent delays.
* Answer any follow-up technical questions about the overview and demo.&#x20;

{% hint style="warning" %}
Ensure that all primary technical contacts are present to address any technical questions about the target environment.
{% endhint %}


# Project components

Split your project into components to easily meet your reporting and mitigation requirements.

***

### What are project components?

Sometimes pentest projects can have a wide and complex scope. When testing one application, your scope might include:

1. Web Application
2. Mobile Application
3. External Network

If you have separate teams responsible for each component, manually splitting the reported vulnerabilities by component can be tedious. Even after you've identified which issues belong to each component, you can't send a separate report to each team for mitigation.&#x20;

Project components solve this issue before it can happen: before the test begins, you can choose whether or not to split your project into multiple components.&#x20;

***

### How do project components help?

During the kickoff call, the testing team will ask you about splitting your project into components. We start with the example component breakdown in the previous section, but you can discuss any component breakdown with the testing team.&#x20;

During the testing phase, we will identify which component each vulnerability belongs to, which  neatly categorizes your vulnerabilities in the report when it is delivered.

***

### How do I use project components in Portal?

After the report is delivered, project components can be used in <code class="expression">space.vars.product\_name</code> on the <mark style="color:orange;">**Project Overview**</mark>, <mark style="color:orange;">**Vulnerabilities**</mark>, and <mark style="color:orange;">**Reports & Executive Summaries**</mark> tabs.

#### Overview

<figure><img src="/files/IAqLW8iV6WqQxFVvjpkN" alt=""><figcaption></figcaption></figure>

When you select one or more components in the filter, the page's contents are filtered to display a summary for only the vulnerabilities that belong to the selected component or components.

#### Vulnerabilities

<figure><img src="/files/eMVsPGlmVBL48UL17BtK" alt=""><figcaption></figcaption></figure>

Each vulnerability displays its associated component or components, and the table has a component filter that you can enable.

#### Reports & Certificates <img src="/files/l8tARWtQELaBMPE3qdgd" alt="" data-size="line">

{% hint style="info" %}
To inquire about upgrading your <code class="expression">space.vars.product\_name</code> package, [speak with sales](mailto:sales@softwaresecured.com).
{% endhint %}

<figure><img src="/files/RR0oJQelv72a7N0dsWN6" alt=""><figcaption></figcaption></figure>

On the <mark style="color:orange;">**Reports & Executive Summaries**</mark> page, component filters can be applied to the most recent pentest. Selecting a component from this filter only displays pentests containing the vulnerabilities that are related to the selected component, and the filter helps generate a new vulnerability summary.

If you apply a component filter, you can download the report or certificate that only includes information about the vulnerabilities that apply to the selected component.&#x20;


# Pentest start date and rescheduling

View the scheduled start date for the next pentest or send a request to reschedule if need.

Knowing when your upcoming penetration test is scheduled can help your team plan in advance to set up your environment, configure your application or system controls, and block time to view and manage vulnerabilities from the report.

Penetration testing dates are planned and agreed on by you and the <code class="expression">space.vars.company\_name</code> Operations team. To ensure that your team has enough time to prepare for the test, <code class="expression">space.vars.company\_name</code> usually schedules tests two weeks—or at minimum, one week—between the Statement of Work (SOW) signature and the start of the pentest.

{% hint style="info" %}
If your test is scheduled more than 2 weeks in advance, you will receive email reminders about your upcoming test, beginning 2 weeks before the pentest start date. These notifications are required.
{% endhint %}

***

### **Viewing the dates assigned to your pentests**

The date listed in <code class="expression">space.vars.product\_name</code> is for when your pentest starts. Based on the complexity of the application and the scope of the pentest, the end date or duration of the test will vary.&#x20;

On the <mark style="color:orange;">**Overview**</mark> tab, the <mark style="color:orange;">**Project Details**</mark> card includes the start date for both your next and last test.&#x20;

<figure><img src="/files/n4AGa8gapasIPTXcUre1" alt=""><figcaption><p><mark style="color:orange;"><strong>Project Details</strong></mark> card on the <mark style="color:orange;"><strong>Overview</strong></mark> tab</p></figcaption></figure>

***

### **Rescheduling your pentests**

1. In the <mark style="color:orange;">**Next Test**</mark> section of <mark style="color:orange;">**Project Details**</mark>, click <mark style="color:orange;">**Change**</mark>.
2. Choose a new date, and include any additional information that <code class="expression">space.vars.company\_name</code> should know about the test.
3. Click <mark style="color:orange;">**Proceed**</mark>.&#x20;

<code class="expression">space.vars.company\_name</code> will review and process the request in a timely manner.&#x20;

{% hint style="warning" %}
When rescheduling your test, you must let the Pentest Manager know at least two weeks before the scheduled start date.&#x20;

Requests that are submitted less than two weeks before the start date have limited flexibility, and rescheduling fees might apply.
{% endhint %}

You will receive multiple notifications to remind you of the start date for your next pentest, either by email or Slack. If you receive reminders on Slack, you can also click the link in the notification to reschedule your test.&#x20;

<figure><img src="/files/13bB07MrDma54QgD3Sks" alt="" width="563"><figcaption><p>Slack notification regarding a pentest start date</p></figcaption></figure>


# During the active pentest

What to expect during active testing.

Once the test has started, leave the rest to us.&#x20;

{% hint style="warning" %}
Our IP address is provided as a part of the pentest checklist; share this IP with your operations or security team so they can distinguish between testing activities and any actual security events that might occur during the testing dates.
{% endhint %}

We may contact you in the following circumstances:

* We have follow-up questions if we encounter something that was not previously discussed.
* We experience any issues with the testing environment that block progress on the test.&#x20;
* We discover critical severity vulnerabilities that represent an imminent danger to the system or your organization. Such issues should be reviewed and addressed as soon as possible. All other vulnerabilities are communicated in the final report.

During the test, we are always available to converse through email or a shared Slack channel. For more information about using Slack, see [Slack](/account/integrations/slack).&#x20;

Reach out if at any point testing activities have become adversely disruptive and you need us to pause temporarily.&#x20;


# Pentest checklist

Understanding the purpose of the pentest checklist and how to find and fill it out.

The pentest checklist is a short questionnaire to help ensure that your team and <code class="expression">space.vars.company\_name</code>'s testing team are both prepared to start the pentest on time. Submitting the pentest checklist on time helps our team maximize their time and provides as much coverage as possible.

The information that <code class="expression">space.vars.company\_name</code> obtains from the pentest checklist gives our team everything that we need to get started quickly on the first day of testing. The contents of the checklist vary depending on the type of testing performed.

{% hint style="info" %}
For a detailed description of what information we need in each section of the checklist, see [Infrastructure summary](/checklist/infrastructure-summary).&#x20;
{% endhint %}

***

### Information requested in the checklist

Two weeks before the pentest's scheduled start date, you will receive reminders to fill out the checklist by email and Slack. Each project has a separate pentest checklist. Because the information is saved automatically, multiple team members can participate in filling out the checklist.&#x20;

The following information is requested in the checklist:

* New features and use cases that are in scope for your pentest, if there is anything new since the last test.
* Availability for a demo meeting.
* Confirmation that the scope is accurate.
* URLs and scoping confirmation for environments.
* x2 sets of access credentials to your system (sent through a secure link).
* VPN configuration information, if applicable.&#x20;

{% hint style="info" %}

#### <code class="expression">space.vars.ptass</code> Clients

You don't need to recomplete this checklist for every test. Once the pentest checklist is completed the first time, you only need to make edits as needed.&#x20;

If you have changes to any element of the questionnaire—such as new features in scope for the test or a new URL to the test environment—update the checklist with this information before your next pentest.
{% endhint %}

***

### Finding and filling out the checklist in Portal

1. Log in to <code class="expression">space.vars.product\_name</code> and select the project where you want to review the checklist.&#x20;
2. On the <mark style="color:orange;">**Overview**</mark> tab, check the status of the checklist in the <mark style="color:orange;">**Project Details**</mark> card.&#x20;
3. To view the detailed checklist, go to the <mark style="color:orange;">**Checklist**</mark> tab. &#x20;
4. Add the required information for each component of your test. For more information, see [Infrastructure summary](/checklist/infrastructure-summary).&#x20;

***

### Checklist FAQ

<details>

<summary>How do I add more than 20 IP addresses to the checklist? </summary>

When you have a large number of IP addresses or hostnames in the testing scope, collect them all in a spreadsheet or CSV file and upload it to the <mark style="color:orange;">**File Dropzone**</mark> for the respective section.

</details>


# Infrastructure summary

Gather all of the information that we need to start the pentest.

<code class="expression">space.vars.company\_name</code> requires various information about your application infrastructure based on the type of pentest that you are receiving. Check the section that corresponds with your test type to see the information that we need to prepare for the test.&#x20;

***

### <i class="fa-globe-pointer">:globe-pointer:</i> Web Application Pentest

#### Target application URLs

Provide a full and precise list of the application URLs that are targets in the testing scope, so we know exactly what needs to be tested (and what shouldn't be). Only include the base URLs of your applications in this list.

#### Application logs (optional)

To provide a more thorough test, provide several (2-3) days worth of application logs. This information helps us understand the application better and identify more vulnerabilities.

#### Documentation (optional)

If your application has any documentation, include a link to it. By using the documentation, we can gain a better understanding of your applications main use cases to help us model common threats against it.

***

### <i class="fa-network-wired">:network-wired:</i> Internal Network Pentest&#x20;

#### IP addresses or ranges

Provide a full and precise list of IP addresses or ranges that are in the testing scope, so we know exactly what needs to be tested (and what shouldn't be).

{% hint style="info" %}
For large target lists, you can upload a file containing your entire list in the pentest checklist. For more information, see the Checklist FAQ on the [Pentest checklist](/checklist/pentest-checklist) page.&#x20;
{% endhint %}

#### Access instructions

Include instructions for accessing the network where we are conducting the pentest. Often, internal networks are accessed through a VPN or bastion host.

***

### <i class="fa-chart-network">:chart-network:</i> External Network Pentest

#### IP addresses, IP address ranges, and hostnames

Provide a full and precise list of any IP addresses, IP address ranges, and hostnames that are in the testing scope, so we know exactly what needs to be tested (and what shouldn't be). Include a short description for each item, and specify the application environment—such as production or staging—as well as whether the item is publicly facing or not.

***

### <i class="fa-cloud">:cloud:</i> Secure Cloud Review

#### Cloud assets

Provide a full and precise list of any IP addresses, IP address ranges, and hostnames that are in the testing scope, so we know exactly what needs to be tested (and what shouldn't be).&#x20;

#### Cloud architecture or topology (optional)

To help us better understand the cloud environment, provide an architectural diagram of your cloud infrastructure. This information allows testers to spend less time trying to map out your infrastructure and more time testing it.

***

### <i class="fa-square-code">:square-code:</i> Secure Code Review

#### Repository access

To complete the review, we need access to your code base. You can provide it to us either by giving us access to the repository ([<mark style="color:orange;">@SoftwareSecuredOperations</mark>](https://github.com/SoftwareSecuredOperations) on GitHub) or by sending us the source code directly.&#x20;

{% hint style="success" %}
To send us the code directly, upload it to the [Pentest checklist](/checklist/pentest-checklist) in <code class="expression">space.vars.product\_name</code>.&#x20;
{% endhint %}

***

### <i class="fa-mobile">:mobile:</i> Mobile Pentest

#### Supported OS versions

Provide the Android and iOS versions that your app supports, as applicable. This information allows us to ensure that we have the appropriate number of devices and install the supported OS versions to complete the test.&#x20;

#### Mobile app binaries

Provide the app binaries—such as APK or IPA—that are going to be tested. To simplify the process, you can directly upload the binary in our [Pentest checklist](/checklist/pentest-checklist).&#x20;

Another binary-sharing method is to give <code class="expression">space.vars.company\_name</code> CI/CD access; however, this method is not as streamlined as using the checklist.

<details>

<summary>Providing CI/CD access to <code class="expression">space.vars.company_name</code></summary>

If you use TestFlight, AppCenter, or a similar application—and if preconditions are satisfied—you might be able to give us access to the mobile binaries through that application.&#x20;

For an iOS application, the target application must support iOS 13.0 (or later? or only 13?) to be compatible with the process required to extract the required files from TestFlight for pen-testing.&#x20;

Grant access to the following email address: <mark style="color:orange;"><pentest@softwaresecured.com></mark>

</details>

#### Tamper or root detection information

Let us know if your application has tampering or root detection capabilities. This information changes how we conduct the portion of the test that focuses on rooted or jailbroken devices.&#x20;

#### Phone features used by the application

Include a list of phone features that your application requires access to in order to function. Examples of phone features include, but are not limited to:

* Microphone
* Location
* Camera
* Bluetooth

#### Build version

To ensure that we are testing the correct version—and to track our work progression if you complete tests on different builds—include the build version or build ID of the application that we are testing.&#x20;


# Service Level Agreements (SLAs)

SLAs determine the appropriate remediation window concerning the risk posed by the vulnerability.

The Service Level Agreement (SLA) outlines the commitment that you make to <code class="expression">space.vars.company\_name</code> when we test your environment—that you will remediate any vulnerabilities in accordance with security best practices and <code class="expression">space.vars.company\_name</code>'s policies or your own internal requirements.&#x20;

***

### Software Secured’s default SLA definition

* <mark style="color:purple;">**Critical**</mark>**:** remediate within business 5 days
* <mark style="color:red;">**High**</mark>**:** remediate within 30 days
* <mark style="color:orange;">**Medium**</mark>**:** remediate within 90 days
* <mark style="color:yellow;">**Low**</mark>**:** remediate within 180 days
* <mark style="color:blue;">**Informational**</mark>**:** no SLA attached as these are best practices.

***

### Track SLA compliance

The <mark style="color:orange;">**Overview**</mark> and <mark style="color:orange;">**Vulnerabilities**</mark> tabs on <code class="expression">space.vars.product\_name</code> include SLA compliance information.&#x20;

* <mark style="color:green;">Compliant</mark> vulnerabilities do not need to be resolved immediately, or they have already been resolved.&#x20;
* <mark style="color:yellow;">At Risk</mark> vulnerabilities are nearing their SLA deadlines.&#x20;
* <mark style="color:red;">Overdue</mark> vulnerabilities have already missed their SLA deadline.&#x20;

#### **Overview tab**

View a general summary of the SLA status for the vulnerabilities within a project.&#x20;

<figure><img src="/files/S4MGLmQSLl1IkCKVWJtW" alt=""><figcaption><p><mark style="color:orange;"><strong>SLA Compliance</strong></mark> pie chart</p></figcaption></figure>

#### **Vulnerabilities tab**

1. Select the project you wish to view, and go to the <mark style="color:orange;">**Vulnerabilities**</mark> tab.&#x20;
2. The <mark style="color:orange;">**SLA**</mark> column in the vulnerabilities table includes the SLA status for each individual vulnerability within your project.

<figure><img src="/files/uzEOegL2zcTPbrUQpygw" alt=""><figcaption><p>The <mark style="color:orange;"><strong>SLA</strong></mark> column indicates the SLA compliance status</p></figcaption></figure>

***

### Change SLA definitions

SLAs vary for each organization depending on the sensitive data stored in your application. You can change the SLA definition in <code class="expression">space.vars.product\_name</code> to match your organization's SLA requirements.

1. In the projects bar, select the project that you would like to change the SLAs for.
2. Click the clock icon ( <i class="fa-clock">:clock:</i> ) in the <mark style="color:orange;">**SLA Compliance**</mark> card.&#x20;

<figure><img src="/files/7PGLikCGkyE3COpzsQ9i" alt=""><figcaption><p>Location of the <mark style="color:orange;"><strong>SLA Settings</strong></mark> button on the <mark style="color:orange;"><strong>Overview</strong></mark> tab</p></figcaption></figure>

3. In the <mark style="color:orange;">**SLA Settings**</mark> modal, update the timeframes to match your internal SLA deadlines.

<figure><img src="https://lh7-us.googleusercontent.com/ltp48oXAIWzhUMQqjrMsrpZexFQ7KRmPUY6VI-xjmEN9EtZhriwyoKlYXwF-TeQn9sYIUTVTZEGCE3eeGOUHEtOmyT-RkYqxHG6Rrlkn8iPFANY1H76EVMje0BWo1Ey0JAlbiXVcFhJmJex-w49UiH8" alt=""><figcaption></figcaption></figure>


# Viewing and acting on your pentest results

View your pentest results in Portal, and begin the remediation process.

After each penetration test, your results are uploaded into <code class="expression">space.vars.product\_name</code>. You will receive a notification by email (and Slack, if you have the integration) when results are available.

***

### **View your results**

1. In the projects bar, select the project that you would like to view.&#x20;
2. Open  the <mark style="color:orange;">**Vulnerabilities**</mark> tab.
3. In the table view, you can view the status, severity, SLA status, date identified, last updated, affected compliance frameworks, and any labels. If you have any project management integrations enabled they will also be visible.

<figure><img src="/files/FuC79UXPGAwTu7sbIlTJ" alt=""><figcaption><p>The <mark style="color:orange;"><strong>Vulnerabilities</strong></mark> tab includes a table of all vulnerabilities in the project.</p></figcaption></figure>

3. Select any vulnerability in the table to review its details, including the description, impact, mitigation tactics, replication steps, evidence, and comments.&#x20;

***

### Remediation actions

After viewing your results, there are actions your team can take to tackle remediation.&#x20;

In the main menu of your project’s vulnerability dashboard, you can take the following actions:

* Book a retest for selected issues (see [Retesting your vulnerabilities](/after-testing/retesting-your-vulnerabilities)).
* Copy vulnerability information to your clipboard.
* Export vulnerability data as a CSV file (see [Viewing and downloading reports and executive summaries](/reports-and-certificates/viewing-and-downloading-reports-and-executive-summaries)).&#x20;
* Add labels.
  * Labels make it easier to categorize and sort vulnerabilities. Users can add up to 50 labels per project, including (but not limited to) release versions, assigned teams, or internal priority.&#x20;
* Accept risk for a vulnerability.&#x20;
  * <mark style="color:orange;">Org Admins</mark> and <mark style="color:orange;">Project Admins</mark> can accept risk by selecting the vulnerability and clicking <mark style="color:orange;">**Accept Risk**</mark>.&#x20;
  * When submitting a request to accept the risk of a vulnerability, you must provide a note to explain why the risk is accepted and timestamp for the acceptance.&#x20;
  * After the request is approved, the issue is assigned the <mark style="color:orange;">**Accepted Risk**</mark> state and will be treated as a <mark style="color:orange;">**Closed**</mark> issue. Therefore, SLAs don’t apply to it.
* Reopening vulnerabilities.&#x20;
  * An vulnerability is reope*n*ed by Software Secured if—after it was first detected and then confirmed to be remediated—it is detected again.
  * If your team chooses to mitigate an issue that you <mark style="color:orange;">**Accepted Risk**</mark> on in the past, you will need to reopen it before you can request retesting.
  * To reopen an issue, select an <mark style="color:orange;">**Accepted Risk**</mark> vulnerability and click <mark style="color:orange;">**Reopen Issue**</mark>.  The issue is then marked with the <mark style="color:orange;">**Updated**</mark> status and the original risk score is applied again. For any new report, the issue is moved back into the main report.&#x20;

{% hint style="info" %}
For more information about tracking remediation efforts, see [Remediating vulnerabilities](/after-testing/remediating-vulnerabilities).&#x20;
{% endhint %}


# Dashboard insights \<WIP>

I don't see where the "dashboard" is in Portal - is that the overview page?

if it is the overview page, I don't think we need this docs page because we don't want to just outline what people see in the UI - it is pretty self explanatory to me.&#x20;


# User management

Add and configure users and their permissions.

When onboarded into the <code class="expression">space.vars.product\_name</code>, only <code class="expression">space.vars.company\_name</code> can assign Org Admins. Once the Org Admins are assigned for the project, they will receive access to <code class="expression">space.vars.product\_name</code> to begin assigning Project Admins and Members.&#x20;

***

### **Roles and permissions**

To ensure the safety and access levels for sensitive information, you must select the roles and permissions for each new user in <code class="expression">space.vars.product\_name</code>.&#x20;

* <mark style="color:orange;">**Org Admin**</mark>

  * Added by <code class="expression">space.vars.company\_name</code>.&#x20;
  * Has all the privileges across all projects.&#x20;

  <div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p>Multiple Org Admins can be assigned to your Portal tenant. To add more Org Admins, contact <a href="mailto:portal@softwaresecured.com">portal@softwaresecured.com</a>.</p></div>
* <mark style="color:orange;">**Project Admin**</mark>
  * Added by an Org Admin.
  * Has all the privileges for specific projects that they are assigned to.
* <mark style="color:orange;">**Member**</mark>
  * Added by both Org Admins and Project Admins.&#x20;
  * Only has access to the projects that they have been added to.&#x20;

***

### User permission table

The following table lists all the roles and the default granular permissions that can be given to each role.&#x20;

{% hint style="info" %}
Portal supports granular permissions, meaning you can assign any user to only have specific permissions from their role.

For example, you can configure Member 1 to be able to request retests and remove that permission for Member 2, or you could give Project Admin 1 permission to accept risk and remove that permission for Project Admin 2.&#x20;
{% endhint %}

<table data-view="cards"><thead><tr><th></th><th>Add New Users</th><th>Change Project SLA's</th><th>Download Report / Certificate</th><th>Accept Risk</th><th>Request Retest</th><th>Request Consulation</th><th>Fill Checklist</th><th>Remove User</th><th>Manage Integrations</th></tr></thead><tbody><tr><td><mark style="color:orange;"><strong>Org Admin</strong></mark></td><td>✅</td><td>✅</td><td>✅</td><td>✅</td><td>✅</td><td>✅</td><td>✅</td><td>✅</td><td>✅</td></tr><tr><td><mark style="color:orange;"><strong>Project Admin</strong></mark></td><td>✅ <sup><sub>(Own projects only)</sub></sup></td><td>✅</td><td>✅</td><td>✅</td><td>✅</td><td>✅</td><td>✅</td><td>❌</td><td>❌</td></tr><tr><td><mark style="color:orange;"><strong>Member</strong></mark></td><td>❌</td><td>❌</td><td>✅</td><td>❌</td><td>✅</td><td>✅</td><td>✅</td><td>❌</td><td>❌</td></tr></tbody></table>

***

### **Adding users in Portal**

1. In the header, navigate to the user profile menu and click <mark style="color:orange;">**Settings**</mark> (or <mark style="color:orange;">**Users**</mark> if you are a Project Admin).&#x20;

<figure><img src="/files/aSAC5wuNDuIhGf5MHypR" alt=""><figcaption><p>User profile menu on the dashboard</p></figcaption></figure>

2. In the **Team** table, click <mark style="color:orange;">**Add User**</mark>.&#x20;

<figure><img src="/files/Btj7tsXLo2K2bmu9KfF5" alt=""><figcaption><p>Team table section of the Settings page</p></figcaption></figure>

3. Enter an email address and choose the role and projects for the new user.&#x20;
4. **Optional:** Customize each role by adding or removing user permissions as required.&#x20;

   <figure><img src="/files/fEDTne5814Ffs4pWHjFF" alt=""><figcaption></figcaption></figure>
5. Click <mark style="color:orange;">**Add**</mark>.


# Integrations

Integrate various third-party software with Portal to increase efficiency for issue remediation and in-test communication.

* [Azure DevOps](/account/integrations/azure-devops)
* [GitHub](/account/integrations/github)
* [GRC tools (Vanta and Drata) \<WIP>](/account/integrations/grc-tools-vanta-and-drata-less-than-wip-greater-than)
* [Jira](/account/integrations/jira)
* [Microsoft Teams](/account/integrations/microsoft-teams)
* [Slack](/account/integrations/slack)


# Azure DevOps

Integrate Azure DevOps and Portal to link your work items to your vulnerabilities.

{% hint style="info" %}
Note: This integration is available with the Standard Plus package or above.
{% endhint %}

### Prerequisites

* An account with <mark style="color:orange;">Org Admin</mark> permissions.

### **Steps**

{% stepper %}
{% step %}

#### Start the integration setup

1. In the <code class="expression">space.vars.product\_name</code> navigation sidebar, locate the <mark style="color:orange;">**Integrations**</mark> page near the bottom and open it
2. Find the Azure integration card, and then click <mark style="color:orange;">**Add Azure Account**</mark>**.**
   {% endstep %}

{% step %}

#### Allow <code class="expression">space.vars.product\_name</code> access to your DevOps Tenant

1. When entering the setup, you might be redirected to the Microsoft login page since Portal requests a scope increase on the permissions that are related to Azure DevOps. Accept the new login scope to continue setup.
2. Depending on how your organization is set up, you might need admin approval to allow <code class="expression">space.vars.product\_name</code> to access your DevOps tenant.
   {% endstep %}

{% step %}

#### Enter your Azure DevOps base URL

1. Each Azure DevOps tenant has its own base URL. <code class="expression">space.vars.product\_name</code> requires your organization's DevOps URL to integrate with it.
2. To find your Azure DevOps tenant URL, log in to your DevOps tenant. You'll see your tenant's URL in the URL bar of your browser, formatted like the following example:\
   `https://dev.azure.com/your_org_name` <br>

   <figure><img src="/files/nH7eJZpMEFhxN7nd6Piq" alt=""><figcaption><p>Enter your Azure DevOps Server URL.</p></figcaption></figure>

{% endstep %}

{% step %}

#### Select projects and boards

1. Select the Azure DevOps Project that you would like to connect. When creating tickets in DevOps from vulnerabilities in <code class="expression">space.vars.product\_name</code>, they will be created in this project.
2. Select the <code class="expression">space.vars.product\_name</code> Project that you would like to connect to.\ <br>

   <figure><img src="/files/2lIwofycLMme0p5Exmds" alt=""><figcaption><p>Select your Azure DevOps project and Portal project for integration.</p></figcaption></figure>

{% endstep %}

{% step %}

#### Configure field mapping

{% hint style="success" %}

#### Note

If you already have fields in Azure that match the name of the fields in <code class="expression">space.vars.product\_name</code>, they are automatically mapped to each other.
{% endhint %}

1. Select the Azure DevOps record type that you would like the integration to use when creating new tickets. You can select any record type from your project.&#x20;
2. If necessary, customize the field mapping by selecting different fields from the dropdown menus.&#x20;

<figure><img src="/files/EWt6OQfFNnWuNYYqn0aw" alt=""><figcaption><p>Configure field mapping between Portal and Azure DevOps.</p></figcaption></figure>
{% endstep %}

{% step %}

#### Review and enable the integration

1. Review your integration configuration.&#x20;
2. To enable the integration, click <mark style="color:orange;">**Finish**</mark>.
   {% endstep %}
   {% endstepper %}

### Results

Use Azure DevOps to track remediation progress for your vulnerabilities. For more information, see [Using integrations to track remediation](/after-testing/remediating-vulnerabilities/using-integrations-to-track-remediation).&#x20;


# GitHub

Convert Vulnerabilities into GitHub Issues to streamline project management.

{% hint style="info" %}
Note: This integration is available with the Standard Plus package or above.
{% endhint %}

{% hint style="warning" %}
What's a GitHub App and why do I need to install it? Read more in the [GitHub Docs](https://docs.github.com/en/apps/using-github-apps/about-using-github-apps).
{% endhint %}

### **Prerequisites**

* A <code class="expression">space.vars.product\_name</code> account with <mark style="color:orange;">Org Admin</mark> permissions.
* A GitHub account that has <mark style="color:blue;">Admin</mark> permissions on the repository that you would like to integrate with. If it's an <mark style="color:blue;">Organization</mark> repository, you need an account with <mark style="color:blue;">Organization Admin</mark> permissions.

### **Steps**

{% stepper %}
{% step %}

#### Start the integration setup

1. In the <code class="expression">space.vars.product\_name</code> navigation sidebar, locate the <mark style="color:orange;">**Integrations**</mark> page near the bottom and open it
2. Find the GitHub integration card, and then click <mark style="color:orange;">**Add GitHub Account**</mark>**.**&#x20;
   {% endstep %}

{% step %}

#### Install the <code class="expression">space.vars.company\_name</code> GitHub App

1. In the integration wizard, click the button to install the Software Secured GitHub App. This app gives <code class="expression">space.vars.product\_name</code> access to create issues in your repository.&#x20;
2. You will be redirected to log in to GitHub. If you're not logged in already, log into your account.
3. When choosing where to install the app, select the owner of the repository that you want to integrate with. This account can be your own account or a GitHub Organization if it's an organization repository.
4. Next, select which repositories the app will have access to. For optimal security for your repositories, only provide access to the repository that you are integrating with <code class="expression">space.vars.product\_name</code>.
5. Click <mark style="color:blue;">**Install**</mark> to finish the process, and you will be redirected back to the integration setup in <code class="expression">space.vars.product\_name</code>.
   {% endstep %}

{% step %}

#### Select your project and repository

1. On <code class="expression">space.vars.product\_name</code>, continue enabling the integration.
2. Select the <code class="expression">space.vars.product\_name</code> Project and GitHub Repository that you would like to connect. When creating GitHub issues from <code class="expression">space.vars.product\_name</code>, they will be created in this repository.

<figure><img src="/files/qxjc1swCPJiTN5W2LJOe" alt=""><figcaption><p>Select your GitHub Repository and <code class="expression">space.vars.product_name</code> Project.</p></figcaption></figure>
{% endstep %}

{% step %}

#### Configure issue fields

1. Configure the vulnerability information that you would like in your GitHub issues. All information is placed in the issue description in Markdown format. <code class="expression">space.vars.product\_name</code> labels can be placed in the description or added as GitHub labels.

<figure><img src="/files/ClcM2Jl0T8XxDo9R0uAM" alt=""><figcaption><p>Choose the vulnerability information to include in GitHub issues.</p></figcaption></figure>
{% endstep %}

{% step %}

#### Review and enable the integration

1. Review your integration configuration.&#x20;
2. To enable the integration, click <mark style="color:orange;">**Finish**</mark>.
   {% endstep %}
   {% endstepper %}

### Results

Use GitHub to track remediation progress for your vulnerabilities. For more information, see [Using integrations to track remediation](/after-testing/remediating-vulnerabilities/using-integrations-to-track-remediation).&#x20;


# GRC tools (Vanta and Drata) \<WIP>

Integrate your Governance, Risk, and Compliance (GRC) tools with Portal to \_\_\_\_\_\_.

**Prerequisites**

An account with <mark style="color:orange;">Org Admin</mark> permissions.

**Steps**

1. Open the user menu icon in the header on your <code class="expression">space.vars.product\_name</code> Dashboard.
2. Go to <mark style="color:orange;">**Settings > Integrations**</mark>**.**
3. Click either <mark style="color:orange;">**Add Vanta Account**</mark> or <mark style="color:orange;">**Add Drata Account**</mark> depending on your GRC tool.&#x20;
4. Follow the steps provided by your GRC tool.

**Results**

After you follow the steps from your GRC tool, you can do \_\_\_\_\_\_.&#x20;


# Jira

Connect your most important Jira boards to streamline project management.

{% hint style="info" %}
Note: This integration is available with the Standard Plus package or above.
{% endhint %}

### **Prerequisites**

An account with <mark style="color:orange;">Org Admin</mark> permissions.

### Steps

{% stepper %}
{% step %}

#### Start the integration setup

1. In the <code class="expression">space.vars.product\_name</code> navigation sidebar, locate the <mark style="color:orange;">**Integrations**</mark> page near the bottom and open it
2. Find the Jira integration card, and then click <mark style="color:orange;">**Add Jira Account**</mark>**.**&#x20;
   {% endstep %}

{% step %}

#### Generate a Jira API token

1. Log in to your Jira account
2. Click your profile icon, and then click <mark style="color:blue;">**Manage Account**</mark>.
3. In the new window, click on the <mark style="color:blue;">**Security**</mark> tab and then click <mark style="color:blue;">**Create and manage API tokens**</mark>.
4. Create a new API token with a relevant name, such as <mark style="color:blue;">`Portal Integration Token`</mark>. Set a long expiry, but not too long; <code class="expression">space.vars.company\_name</code> recommends 1 year.
5. Copy the token.&#x20;
   {% endstep %}

{% step %}

#### Connect <code class="expression">space.vars.product\_name</code> to Jira

1. On <code class="expression">space.vars.product\_name</code>, continue enabling the integration.
2. In the server URL, enter the domain of your Jira tenant. The URL usually looks like the following example: <mark style="color:blue;">`<your-company>.atlassian.com`</mark>
3. Enter your Jira username and the API token from step 2, and then click <mark style="color:orange;">**Next**</mark>.

<figure><img src="/files/eepWrq5hNRmbjK848w1c" alt=""><figcaption><p>Add your Jira account that you want to integrate with Portal.</p></figcaption></figure>
{% endstep %}

{% step %}

#### Select projects and boards

1. Select the Jira Project that you would like to connect. When creating tickets in Jira from vulnerabilities in <code class="expression">space.vars.product\_name</code>, they will be created in this project.
2. Select the <code class="expression">space.vars.product\_name</code> Project that you would like to connect to.<br>

   <figure><img src="/files/1GfrIGNu88PGYqbNOneG" alt=""><figcaption><p>Choose the projects and boards to integrate. </p></figcaption></figure>

{% endstep %}

{% step %}

#### Configure field mapping

{% hint style="success" %}

#### Note

If you already have fields in Jira that match the name of the fields in <code class="expression">space.vars.product\_name</code>, they are automatically mapped to each other.
{% endhint %}

1. Select the Jira record type that you would like the integration to use when creating new records. You can select any record type from your project.&#x20;
2. If necessary, customize the field mapping by selecting different fields from the dropdown menus. <br>

   <figure><img src="/files/fJxMJn4DbFZYebd3tl5a" alt=""><figcaption><p>Choose which fields in Portal will populate which fields in Jira.</p></figcaption></figure>

{% endstep %}

{% step %}

#### Review and enable the integration

1. Review your integration configuration.&#x20;
2. To enable the integration, click <mark style="color:orange;">**Finish**</mark>.
   {% endstep %}
   {% endstepper %}

### Results

Use Jira to track remediation progress for your vulnerabilities. For more information, see [Using integrations to track remediation](/after-testing/remediating-vulnerabilities/using-integrations-to-track-remediation).&#x20;


# Microsoft Teams

Follow these steps to create a webhook and connect your Teams channel to Portal notifications.

### **Prerequisites**

A <code class="expression">space.vars.product\_name</code> account with <mark style="color:orange;">Org Admin</mark> permissions.

### Steps

{% stepper %}
{% step %}

#### Open Workflows

1. In Microsoft Teams, find the channel that you want to receive notifications in.
2. Hover over the channel name and click the **•••** (three dots) menu that appears.
3. In the menu, select <mark style="color:blue;">**Workflows**</mark>**.**
   {% endstep %}

{% step %}

#### Create a Workflow

1. In the Workflows panel, click <mark style="color:blue;">**Workflows Home**</mark> (lower-right corner).&#x20;
2. Click <mark style="color:blue;">**Build from scratch**</mark> (upper-right corner).
   {% endstep %}

{% step %}

#### Select a Trigger

1. Click <mark style="color:blue;">**Select a trigger**</mark>**.**
2. To see all available triggers, click <mark style="color:blue;">**Build with Power Automate**</mark>.
3. Select the <mark style="color:blue;">**Built-in**</mark> tab, then select <mark style="color:blue;">**Microsoft Teams**</mark> from the list.&#x20;
4. Choose <mark style="color:blue;">**When a Teams webhook request is received**</mark>.
5. For <mark style="color:blue;">**Who can trigger the flow?**</mark>, select <mark style="color:blue;">**Anyone**</mark>.
6. Leave the <mark style="color:blue;">**HTTP POST URL**</mark> field blank. It will be auto-generated when you save.&#x20;
   {% endstep %}

{% step %}

#### Add an Action

1. Click <mark style="color:blue;">**+ New Step**</mark>, then search for and select <mark style="color:blue;">**Microsoft Teams**</mark>.
2. Search for and select <mark style="color:blue;">**Post message in a chat or channel**</mark>**.**
3. Configure the following options:
   * <mark style="color:blue;">**Post as**</mark> → Flow bot.
   * <mark style="color:blue;">**Post in**</mark> → Channel.
   * <mark style="color:blue;">**Team**</mark> → Select your team name.
   * <mark style="color:blue;">**Channel**</mark> → Select your channel name.
     {% endstep %}

{% step %}

#### Configure the Message

1. Click on the <mark style="color:blue;">**Message**</mark> text area.
2. In the popup that appears, select <mark style="color:blue;">**Expression**</mark>**.**
3. Enter the following expression and click <mark style="color:blue;">**OK**</mark>:

   ```
   triggerBody()?['text']
   ```
4. Click <mark style="color:blue;">**Save**</mark> and wait for it to save.
5. Close the Workflows panel.
   {% endstep %}

{% step %}

#### Copy your Webhook URL

1. Hover over your channel and click the **•••** (three dots) menu again.
2. Select <mark style="color:blue;">**Workflows**</mark>.
3. Scroll to <mark style="color:blue;">**Your workflows**</mark> and click the workflow you just created.&#x20;
4. Click <mark style="color:blue;">**Copy webhook link**</mark> to copy the URL to your clipboard.
   {% endstep %}

{% step %}

#### Connect to Portal

1. Go to <mark style="color:orange;">**Portal → Integrations → Microsoft Teams**</mark>.
2. Paste the copied URL into the <mark style="color:orange;">**Webhook URL**</mark> field.&#x20;
3. Enter the name of the channel you connected (such as `alerts`)
4. Click <mark style="color:orange;">**Connect Teams**</mark>.
   {% endstep %}
   {% endstepper %}

### Results

Your channel will now receive notifications from <code class="expression">space.vars.product\_name</code>.&#x20;


# Slack

Integrate Slack and Portal to receive testing updates in your Slack workspace.

#### Prerequisites

* A Slack workspace that allows integrations.&#x20;
* An account with <mark style="color:orange;">Org Admin</mark> permissions.

#### Steps

1. Click the user menu icon in the header on your <code class="expression">space.vars.product\_name</code> Dashboard.
2. Go to <mark style="color:orange;">**Settings > Integrations**</mark>**.**&#x20;
3. Click <mark style="color:orange;">**Connect Slack Account**</mark> button, and follow the steps provided by Slack.
4. You will be redirected back to <code class="expression">space.vars.product\_name</code> and see settings for Slack notifications under the <mark style="color:orange;">**Notifications**</mark> section within <mark style="color:orange;">**Settings**</mark>. Turn them on or off based on on which ones you want to receive.

#### Results

You will see the name of your Slack workspace and Slack channel that you have permitted <code class="expression">space.vars.product\_name</code> to post messages to under the <mark style="color:orange;">**Integrations**</mark> section.

The following screenshots show examples of the <code class="expression">space.vars.product\_name</code> notification types that you can configure in Slack.&#x20;

<figure><img src="/files/AB9pdBTTuScakM1aFLtS" alt="Slack notification reminding you to complete the checklist"><figcaption></figcaption></figure>

<figure><img src="/files/4gYccAkAPHlEW1Dgu9du" alt="Slack notification when user action is required"><figcaption></figcaption></figure>

<figure><img src="/files/KD2SAxFi98FzA0ld0N5Y" alt="Slack notification when a new pentest report is available"><figcaption></figcaption></figure>


# Remediating vulnerabilities

The report includes mitigations for the vulnerabilities that were discovered during testing.

To meet the requirements of your [Service Level Agreements (SLAs)](/findings/service-level-agreements-slas), you must remediate your vulnerabilities or accept the risks. The exact way that you will remediate any issues varies from company to company, but the report includes remediations and mitigations to prevent further exploitation. Some mitigations are mandatory to remediate the issue, while others are optional to help strengthen security in your environment.&#x20;

You can export vulnerability information in CSV format to add the information to your desired issue tracking system. For more information, see [Viewing and downloading reports and executive summaries](/reports-and-certificates/viewing-and-downloading-reports-and-executive-summaries).&#x20;

{% hint style="info" %} <img src="/files/l8tARWtQELaBMPE3qdgd" alt="" data-size="line"> Integrate Jira with Portal to track remediation progress. For more information, see [Jira](/account/integrations/jira) and [Using integrations to track remediation](/after-testing/remediating-vulnerabilities/using-integrations-to-track-remediation).&#x20;
{% endhint %}


# Using integrations to track remediation

Create new work items or link existing work items from your project management platform to your vulnerabilities in Portal.

{% hint style="info" %}
Note: These integrations are available with the Standard Plus package or above.
{% endhint %}

{% hint style="warning" %}

#### Prerequisites

Setup a ticketing integration in <code class="expression">space.vars.product\_name</code>. For more information, see:

* [Azure DevOps](/account/integrations/azure-devops)
* [GitHub](/account/integrations/github)
* &#x20;[Jira](/account/integrations/jira)
  {% endhint %}

<figure><img src="/files/bXMXC8YJJgTWHu24oxgH" alt=""><figcaption><p>Ways to use the Jira integration on the <mark style="color:orange;"><strong>Vulnerabilities</strong></mark> page. </p></figcaption></figure>

***

### **Create work items**

This procedure uses the configured field mapping for the integration to create new work items in your project management platform for each of the vulnerabilities that you select.&#x20;

**Steps**

1. Go to the <mark style="color:orange;">**Vulnerabilities**</mark> page.&#x20;
2. Using the multiselect option, select the vulnerabilities that you want to create a work item for.&#x20;
3. In the bulk actions dropdown, use the option to create work items for your project management platform.

**Results**

These work items are created in your integrated platform with the default status.

***

### Link an unconnected vulnerability to a work item

Complete these steps to link a single vulnerability to a work item on an integrated platform.&#x20;

**Steps**

1. On the <mark style="color:orange;">**Vulnerabilities**</mark> page, identify a vulnerability that is not connected to a work item.&#x20;
2. Click the <mark style="color:red;">**Not Connected**</mark> option in the integration column for the vulnerability.&#x20;
3. In the <mark style="color:orange;">**Select Task**</mark> menu, select the work item that you would like to link to the vulnerability, and then click <mark style="color:orange;">**Complete**</mark>.

**Results**

The work item is linked to the vulnerability in <code class="expression">space.vars.product\_name</code>.

***

### <mark style="color:blue;">Jira</mark> <i class="fa-jira">:jira:</i>: Link existing issues to multiple vulnerabilities

If you already created Jira issues to track your vulnerabilities, you can link those issues to <code class="expression">space.vars.product\_name</code> vulnerabilities. By using a custom UID field to indicate which Jira issue maps to which vulnerability, you can connect all of your issues with one click.

**Steps**

1. Go to the <mark style="color:orange;">**Vulnerabilities**</mark> page.&#x20;
2. Using the multiselect option, choose which vulnerabilities you would like to link.
3. In the modal, select which field in your Jira issues contains the issue UID (such as <kbd><mark style="color:blue;">FZBZ001<mark style="color:blue;"></kbd>).&#x20;
   * This field can be any field that *contains* the UID—it doesn't have to be a field that has *only* the UID.&#x20;
   * For example, if your issue titles contain the UID, you can use the title field.
4. Click <mark style="color:orange;">**Next**</mark>.
5. Review the mappings that <code class="expression">space.vars.product\_name</code> identified. If mapping issues appear, resolve any UID mismatches in your Jira issues.&#x20;
6. When the valid mappings are correct, click <mark style="color:orange;">**Save**</mark> to link all of your vulnerabilities.

**Results**

The vulnerabilities are all linked to their corresponding Jira issues.&#x20;


# Retesting your vulnerabilities

What is included in a retest, and how to request a retest in Portal.

The goal for many clients is to remediate reported vulnerabilities, have the remediation validated, and obtain evidence that they have done so for any stakeholders, auditors, or customers.&#x20;

Depending on the size of the report and availability, <code class="expression">space.vars.company\_name</code> can typically support retesting within two weeks of the request being submitted. For maximum flexibility—and if you have a tight timetable—let us know as soon as you have an estimated time for remediation completion, and we can then schedule a retest date.

***

### Retest overview

A retest involves testing the previously reported vulnerabilities to verify that they have been remediated properly. Retests do not identify new vulnerabilities unless new vulnerabilities arise as a direct result of remediation.&#x20;

Depending on your internal SLAs and timelines, you can either retest all vulnerabilities or only a subset, such as high or critical severity vulnerabilities only. You can choose which vulnerabilities to include when you submit the retesting request.&#x20;

{% hint style="warning" %}
Confirm whether the retesting is occurring within the same environment and the same accounts as the initial test, or if it is being completed in a new environment or with new accounts.
{% endhint %}

When the retest is complete, <code class="expression">space.vars.company\_name</code> will provide a new report with the updated status of the vulnerabilities. If any vulnerabilities were not be effectively fixed, this will be indicated in the updated report with supporting comments or evidence.&#x20;

{% hint style="info" %} <code class="expression">space.vars.company\_name</code> can support a maximum of 1 round of retesting for Pentest Standard, 3 rounds of retesting for Pentest Standard Plus, and unlimited retesting for <code class="expression">space.vars.ptass</code> and Premium clients to validate revised remediation, subject to schedule availability. Further retesting might be possible for an additional fee. For more information, see [Software Secured - Pricing and Service Packages](https://www.softwaresecured.com/pricing).&#x20;
{% endhint %}

***

### **Requesting a retest**

1. In the projects bar, select the project that you would like to view.&#x20;
2. Go to the <mark style="color:orange;">**Vulnerabilities**</mark> tab.
3. Using the table multiselect, select the vulnerabilities that you would like to request a retest on, and then click <mark style="color:orange;">**Add to Retest**</mark> from the bulk actions dropdown.
4. Alternatively, you can right click any item from the table and use the <mark style="color:orange;">**Add to Retest**</mark> option from the context menu.

<figure><img src="/files/92yPucHHkYjOSe0aQlOl" alt=""><figcaption></figcaption></figure>

4. To view your retest request, click <mark style="color:orange;">**Submit Retest**</mark>.&#x20;
5. The <mark style="color:orange;">**Retesting Round**</mark> modal displays the details of the items in your retest batch.&#x20;
   * You can go back to the vulnerabilities table and add more items to the retest round with the <mark style="color:orange;">**Add to Retest**</mark> button.&#x20;
   * If you have any notes about the issues to retest or the retest environment, you can include them in the note field.&#x20;
6. Once all issues are in the retesting round, click <mark style="color:orange;">**Submit Request**</mark>.

<figure><img src="/files/i8b1ZiUEgFpLkxEHYDPx" alt=""><figcaption></figcaption></figure>

***

### Retest results

After a retest, the status of your vulnerabilities can change. You will receive a notification by email, Slack, or both every time new results are available for your project (or projects, if applicable) in <code class="expression">space.vars.product\_name</code>.&#x20;

Any vulnerabilities that were marked with a <mark style="color:orange;">**New**</mark> status will be changed to the <mark style="color:orange;">**Updated**</mark> status, and the <mark style="color:orange;">**Last updated**</mark> date will change to the date of the most recent retest.&#x20;

If a known vulnerability was remediated successfully, its status will change to <mark style="color:orange;">**Closed**</mark> and the SLA status will change to <mark style="color:green;">**Compliant**</mark>. If the issue remains unresolved, its SLA status does not change because the SLA policy begins on the date that the vulnerability was first found.


# Consultation requests

What is included with consultation, and how to request a consultation in Portal.

One of the key advantages of [Penetration Testing as a Service (PTaaS)](https://www.softwaresecured.com/service/penetration-testing-as-a-service) with <code class="expression">space.vars.company\_name</code> is the consultation hours with a team of skilled professionals whenever you require security expertise.&#x20;

***

### How to use consulting hours

Our clients leverage their consulting hours in a variety of ways to manage risk.&#x20;

#### Parameters for consulting hours

The options for using the consultation hours are flexible as long as they fit within the following basic parameters:

* The topics discussed during the consultation must be directly tied to the security of the systems that we tested.&#x20;
  * While our team knows a lot about security and security implications of various subjects, they are not suited to provide operational assistance with tasks that are usually performed by Development, DevOps, IT, QA, Compliance Managers, and so on. For appropriate referrals, contact our sales and partnership team.
* Consulting hours cannot be substituted for testing or training hours.

***

#### Common uses for consulting hours

* Actionable and comprehensive advice on vulnerability mitigation based on the results from <code class="expression">space.vars.company\_name</code>’s pentests.
* Advice on security controls for new features that are being designed or considered for the product roadmap.
* Education on how to proactively threat model as a part of your Software Development Lifecycle (SDLC).
* Analysis of third-party vulnerability reports—such as bug bounties or external researchers—or disclosures, including validation and a calibrated risk assessment.
* Information and suggestions for implementing effective and secure engineering practices and policies based on your attack surface and business goals.
* Quick identification of possible threats or exposures to new or emerging vulnerabilities.

***

### **Requesting a consultation**      &#x20;

1. Click the user menu icon in the header on your <code class="expression">space.vars.product\_name</code> Dashboard.
2. Click <mark style="color:orange;">**Request Consultation**</mark>.&#x20;
3. In the <mark style="color:orange;">**Consultation Request**</mark> pop-up, enter a topic or message for discussion during the consultation.&#x20;
4. To submit the request, click <mark style="color:orange;">**Proceed**</mark>.&#x20;

Once the request is approved, you will be contacted by someone from the testing team to schedule the consultation hours.

<figure><img src="https://lh7-us.googleusercontent.com/qRDf9--ppdkf2vRz_Fy4tNiwZscnFGvR_3laaQ6ET1KT4uiNOaKxn-NJXNVSzyaHrFYfslAqm7JK5SZn-JEa-10z97jITazXGxSlg5KETWBSGNMGxUtgPsrYNxVXTlOy6ioGXabx9JbmjLloIEvK4yE" alt="" width="563"><figcaption></figcaption></figure>


# Viewing and downloading reports and executive summaries

How to download the pentest results including the pentest report, certificate, and CSV export.

### **Reports** &#x20;

The final report is typically delivered two business days after the end date of active testing. Once testing is completed—and before we send the report—we fully scrutinize and evaluate the findings, collect any final necessary evidence, calibrate the risk, and perform internal QA on the report document. The document is one inclusive report for all components within scope unless other requirements were outlined before active testing began.

**The report includes the following information:**

* Table of contents
* Testing overview
* Testing dates
* Specific assets and components in scope
* Calibrated scoring overview
* Uniquely numbered sections for each vulnerability, including:
  * Vulnerability name and class
  * Vulnerability severity for both impact (CVSS) and risk (DREAD)
  * Vulnerability location and affected entities
  * Description of the vulnerability
  * Specific impact of the vulnerability (also reflected in scoring)
  * Mitigation (remediation) solutions and security recommendations
  * Steps to replicate (reproduce) each issue
  * Evidence or Proof of Concept (POC) for each vulnerability (or both, if necessary)
  * Additional external links and references

The pentest report is delivered directly through Portal. This allows you to easily control who has access to the report by managing your portal users and their permissions.

{% hint style="success" %}
We strive to make the report as detailed and actionable as possible; let us know if you require additional information. We can schedule a read-out call to go over the report in detail, or we can answer questions over email or Slack.&#x20;
{% endhint %}

#### **Downloading your PDF pentest report**

1. In the project selection bar, choose which project you would like to download a report for.&#x20;
2. Open the <mark style="color:orange;">**Reports & Executive Summaries**</mark> tab.&#x20;
3. **Optional:** Click <mark style="color:orange;">**Customize Report**</mark> to change what appears in the downloaded report or executive summary.&#x20;
4. Click the download button for the desired pentest, and select the report option.

<figure><img src="/files/qOPWNpYHKqhXSVxQmN0h" alt=""><figcaption><p><mark style="color:orange;"><strong>Reports &#x26; Certificates</strong></mark> tab</p></figcaption></figure>

***

### **Executive Summaries**

The pentest Executive Summary is an externally facing document that is a condensed version of the report. This document is best suited to be distributed to clients, auditors, and other external stakeholders.&#x20;

#### **Download the pentest executive summary**

1. In the project selection bar, choose which project you would like to download a certificate for.&#x20;
2. Open the <mark style="color:orange;">**Reports & Executive Summaries**</mark> tab.&#x20;
3. Use the test range selector to view the pentests that you want to view—either by date range or by test.&#x20;
4. **Optional:** Click <mark style="color:orange;">**Customize Executive Summary**</mark> to change what appears in the downloaded executive summary.&#x20;
5. Click the download button for the desired pentest, and select the executive summary option or the abbreviated executive summary option.

***

### **Exporting vulnerabilities as CSV**

Exporting your vulnerability information in a `.csv` file is an easy way to help move the information into other bug-tracking platforms that you may use. Copying vulnerability information to your clipboard is another easy way to help move the information into your bug-tracking platform.

1. In the project selection bar, choose which project you would like to export vulnerability information for.&#x20;
2. Open the <mark style="color:orange;">**Vulnerabilities**</mark> tab.&#x20;
3. Using the table multiselect, select the vulnerabilities that you want to include in the CSV file.
4. Click <mark style="color:orange;">**Export CSV**</mark> from the bulk actions dropdown.

<figure><img src="/files/aXXC2cpF8j37RW1sNjoy" alt=""><figcaption><p>Export vulnerabilities in CSV format on the <mark style="color:orange;"><strong>Vulnerabilities</strong></mark> tab</p></figcaption></figure>


# Testing methodologies \<WIP>

Not sure what content to go here. Something from the website? Or do we have other info somewhere?


# Generating a HAR File

If our support team has asked you to provide a HAR file, this guide will walk you through how to generate and export one from your browser.

## What is a HAR File?

A HAR (HTTP Archive) file is a recording of all network activity between your browser and a website during a session. It helps our support team diagnose issues — like login problems or pages not loading correctly — without needing to reproduce the exact conditions on our end.

{% hint style="warning" %}
**Security Warning:** HAR files contain sensitive data, including cookies, session tokens, and any information submitted while recording (such as passwords). **Only send your HAR file to trusted recipients over a secure channel.** Do not share it via plain email. If you are concerned, ask our support team for a secure upload link.
{% endhint %}

## Google Chrome

{% stepper %}
{% step %}

### Open the affected page

Open Chrome and navigate to the page where the issue occurs.
{% endstep %}

{% step %}

### Open Developer Tools

Press `F12` (Windows/Linux) or `Cmd + Option + I` (Mac).

Alternatively, click the **⋮** menu → **More Tools** → **Developer Tools**.
{% endstep %}

{% step %}

### Select the Network tab

Select the **Network** tab.
{% endstep %}

{% step %}

### Preserve the log

Check the **Preserve log** checkbox so that activity is not cleared on page navigation.
{% endstep %}

{% step %}

### Clear existing entries

Click the **🚫 (Clear)** button to remove any existing log entries and start fresh.
{% endstep %}

{% step %}

### Reproduce the issue

Reproduce the issue (e.g., attempt to log in again).
{% endstep %}

{% step %}

### Export the HAR file

Once the issue has occurred, click the **⬇️ (Export HAR)** button in the Network tab toolbar.
{% endstep %}

{% step %}

### Save the file

Select **Save as HAR with Content** and save the file to your device.
{% endstep %}

{% step %}

### Send the file securely

Send the file to our support team via the provided secure link.
{% endstep %}
{% endstepper %}

## Mozilla Firefox

{% stepper %}
{% step %}

### Open the affected page

Open Firefox and navigate to the page where the issue occurs.
{% endstep %}

{% step %}

### Open Developer Tools

Press `F12` (Windows/Linux) or `Cmd + Option + I` (Mac).
{% endstep %}

{% step %}

### Select the Network tab

Select the **Network** tab.
{% endstep %}

{% step %}

### Persist logs

Click the **⚙️ (Settings)** gear icon in the top-right of the panel and enable **Persist Logs** so that activity is preserved across page loads.
{% endstep %}

{% step %}

### Reproduce the issue

Reproduce the issue (e.g., attempt to log in again).
{% endstep %}

{% step %}

### Save the HAR file

Once the issue has occurred, right-click anywhere in the list of network requests and select **Save All As HAR**.
{% endstep %}

{% step %}

### Save the file

Save the file to your device.
{% endstep %}

{% step %}

### Send the file securely

Send the file to our support team via the provided secure link.
{% endstep %}
{% endstepper %}

## Safari (Mac only)

Safari requires you to enable its developer tools before you can export a HAR file. You only need to do this once.

### Enable Developer Tools

{% stepper %}
{% step %}

### Open Safari settings

Open Safari and go to **Safari** → **Settings** (or **Preferences** on older versions of macOS).
{% endstep %}

{% step %}

### Open Advanced settings

Click the **Advanced** tab.
{% endstep %}

{% step %}

### Enable developer features

Check the box labelled **"Show features for web developers"** (or **"Show Develop menu in menu bar"** on older versions).
{% endstep %}

{% step %}

### Close Settings

Close the Settings window.
{% endstep %}
{% endstepper %}

### Record & Export

{% stepper %}
{% step %}

### Open the affected page

Navigate to the page where the issue occurs.
{% endstep %}

{% step %}

### Open Web Inspector

Click the **Develop** menu in the menu bar and select **Show Web Inspector**.

Alternatively, right-click anywhere on the page and select **Inspect Element**.
{% endstep %}

{% step %}

### Select the Network tab

Click the **Network** tab in the Web Inspector panel.
{% endstep %}

{% step %}

### Preserve the log

Check the **Preserve Log** option so that activity is not lost on page navigation.
{% endstep %}

{% step %}

### Reproduce the issue

Reproduce the issue (e.g., attempt to log in again).
{% endstep %}

{% step %}

### Export the HAR file

Once the issue has occurred, click the **Export** button in the Network tab toolbar and save the file to your device.
{% endstep %}

{% step %}

### Send the file securely

Send the file to our support team via the provided secure link.
{% endstep %}
{% endstepper %}

{% hint style="info" %}
**Tip:** If the Network tab appears empty, try reloading the page *after* opening the Web Inspector.
{% endhint %}

## Sending Your HAR File

Once you have your HAR file, please **do not attach it to a standard email**. Instead, use the secure upload link provided by our support team in your ticket. If you haven't received one, reply to your support ticket and ask for a secure upload link before sharing the file.

If you have any trouble generating your HAR file, let us know what browser and operating system you are using and we will do our best to assist you further.


# Part 1: 5 Myths that will Slow Down Vulnerability Remediation

Security myths create a false sense of safety, causing engineering teams to either take on unnecessary work or overlook critical vulnerabilities, leaving organizations exposed. A strong security culture, focused on risk-based remediation, reduces exposure time and builds trust. With 65% of B2B buyers prioritizing security, high-performing teams that fix issues quickly gain a competitive edge.&#x20;

## The 5 Security Myths and the Truths Behind Them

### Myth #1: “I Have to Fix All Vulnerabilities.”

**The Myth:** It’s common for teams to feel that every single vulnerability uncovered needs immediate remediation. After all, any weakness could be the one an attacker exploits, right? This myth leads to overwhelmed backlogs and burnout as teams scramble to patch low-risk issues alongside critical ones.

**The Truth:** Not all vulnerabilities carry the same risk. Effective security teams prioritize based on impact and likelihood. Industry research shows that only a small fraction of known vulnerabilities ever get exploited in the wild – roughly 5% or fewer. Trying to “fix everything” at once is not just unrealistic; it diverts attention from the critical issues that matter most. A risk-based approach is key: focus on vulnerabilities that present the highest threat to your applications and data. Software Secured scores each vulnerability using two industry standards CVSS and DREAD.&#x20;

By using a calculated approach to risk,and contextual business impact, technical leaders can ensure the team fixes the most dangerous flaws first. This approach accelerates the remediation of what truly counts rather than flooding the team with low-priority fixes. The result is faster reduction of overall risk and more efficient use of engineering effort. This would also reduce the likelihood of urgency fatigue, something that takes place when developers are constantly pushed to close the next security gap, without risk being prioritized. This dynamic can lead to more friction between departments and developers not taking future reports seriously, when it really matters.

### Myth #2: “Fixing Vulnerabilities Will Slow My Development Team.”

**The Myth:** Some engineers and product managers believe that prioritizing security fixes will slow down development velocity and impact feature delivery.

**The Truth:** With proper planning, a prioritized approach based on risk, and expert guidance from your friends at Software Secured, remediation doesn’t have to be as time-consuming.&#x20;

By tackling the most critical vulnerabilities first and integrating security into the development workflow, teams minimize rework and avoid last-minute disruptions.&#x20;

Leveraging the expertise of the Software Secured team ensures efficient fixes, while automated security testing and DevSecOps practices catch issues early—preventing bottlenecks and keeping development on track. Organizations that embed security into their SDLC experience fewer incidents, reducing unplanned work and accelerating future development.

### Myth #3: “Fixing Vulnerabilities is Less of a Priority Than Pushing New Features.”

The Myth: Some leadership teams see security fixes as secondary to feature development, believing they can always be handled later when time permits.

The Truth: While pushing new features is critical for business growth, neglecting security debt can create long-term costs that far outweigh short-term gains.&#x20;

Ignored vulnerabilities compound over time, making remediation more difficult and expensive. Worse, a security breach caused by an unaddressed issue can lead to reputational damage, legal liability, customer churn and financial loss.

Failing to prioritize security can also become a major roadblock when selling to large enterprises that demand strong security assurances. Many enterprise buyers have strict security requirements and will not engage with vendors who cannot demonstrate a proactive approach to vulnerability management.

### Myth #4: “The Pentesters Can't Help Me With Remediation.”

The Myth: Some engineering teams assume that penetration testers only find issues and don’t assist with fixing them.

The Truth: Software Secured offers remediation guidance, best practices, and even proof-of-concept fixes in many scenarios. You should leverage their expertise by discussing recommended mitigations, alternative fixes, and defensive strategies. Treat Software Secured’s penetration testers as partners rather than adversaries, and use their findings to strengthen long-term security improvements.

### Myth #5: “I Will Fix the Vulnerability When Clients Ask.”

The Myth: Some teams delay fixing security issues until customers raise concerns, believing that if no one is complaining, the issue isn’t urgent.

The Truth: Waiting for a client to flag a vulnerability means you're already behind. Proactively addressing vulnerabilities builds trust and prevents damage before it occurs. Many enterprises evaluate security maturity when selecting vendors, and a proactive security posture can be a competitive differentiator. Additionally, attackers don’t wait for customer complaints – if a vulnerability exists, it could already be exploited before anyone reports it. Prioritizing security without external pressure demonstrates leadership, long-term thinking and also avoids the effort of recovering from a public exploit. Something that can be very difficult if not impossible to rebuild your reputation from.\ <br>


# Part 2: Treating Vulnerabilities As Business Risks Accelerates Remediation

Technical leaders often view security vulnerabilities as just another defect in the backlog. However, this mindset is limiting and can lead to inefficient remediation. Unlike regular software bugs, which affect functionality, security vulnerabilities expose an organization to threats, making them business risks.

#### Why vulnerabilities should not be treated as just bugs:

* Bugs typically have two options: fix or ignore.
* Vulnerabilities represent risk and require a broader decision-making approach.
* Fixing every vulnerability without assessing business impact is inefficient.
* A risk-based approach ensures that resources are used effectively to reduce overall security exposure.

#### <mark style="color:red;">Instead of asking, "How do we fix this bug?" teams should ask, "How do we best manage this risk?"</mark>

***

## Vulnerabilities Are Risks, Not Just Bugs

#### Key Differences Between Bugs and Vulnerabilities:

| Aspect             | Bugs                                        | Vulnerabilities                                       |
| ------------------ | ------------------------------------------- | ----------------------------------------------------- |
| Definition         | A software defect affecting functionality.  | A weakness that can be exploited by attackers.        |
| Impact             | Causes system errors or performance issues. | Leads to security breaches, data loss, or downtime.   |
| Resolution Options | Fix it or leave it as tech debt.            | Multiple options: fix, mitigate, delegate, or accept. |
| Priority Decision  | Based on usability & performance.           | Based on risk, and impact.                            |

Because vulnerabilities introduce business risks, they must be managed using a structured risk response approach rather than a simple "fix or ignore" strategy.

***

## The Four Ways to Handle Risk

Security risk management offers four strategies for dealing with vulnerabilities:

### 1. Eliminate the Risk (Fix the Vulnerability)

* The best solution when practical.
* **Examples:**
  * Fixing the root cause of the vulnerability: for example using parametrized SQL statements instead of concatenating strings to fix SQL injection or using contextual output encoding to fix Cross-Site Scripting vulnerabilities.
  * Removing unused or unnecessary services: Disabling or uninstalling outdated services that expand the attack surface without providing business value.
  * Refactoring insecure code: Eliminating risky code patterns such as hardcoded credentials, SQL injection-prone queries, or improper authentication flows.
  * Deploying secure configurations: Enforcing secure defaults and best practices for software, such as turning off directory listings in web servers or disabling weak encryption ciphers.
* **Pros:** Permanently resolves the issue.
* **Cons:** May not always be feasible due to cost or complexity.
* **Best for:** Critical, High and Medium risk issue

### 2. Delegate the Risk (Transfer Responsibility)

* Shifts the security burden to a third party.
* Examples:
  * Relying on a third-party authentication provider: Offloading authentication and authorization to providers like Auth0, Okta, or AWS Cognito instead of managing in-house identity security.
  * Leveraging security controls from external APIs and SDKs: Using vetted libraries for cryptography, payment processing, or secure communication rather than building security-sensitive features from scratch. ([link](https://www.softwaresecured.com/post/top-10-credential-based-attacks))
  * Relying on a DDoS protection service: Utilizing cloud-based services like Cloudflare, AWS Shield, or Akamai to mitigate distributed denial-of-service attacks.
* Pros: Allows specialized teams or services to handle security, reducing internal effort.
* Cons: Requires clear agreements and trust in third parties.
* Best suited for: Issues that will take a long time to resolve.

### 3. Mitigate the Risk (Reduce Impact or Likelihood)

* When fixing is not feasible, implement safeguards to reduce risk with a compensating control.
* Examples:
  * Deploying a Web Application Firewall (WAF): Provides a layer of protection for web applications from malicious requests and automated attacks. WAFs makes it harder to exploit certain vulnerabilities which reduces the likelihood of exploitation.&#x20;
  * Using managed endpoint security solutions: Implementing endpoint detection and response (EDR) solutions such as CrowdStrike, Microsoft Defender for Endpoint, or SentinelOne to offload threat detection and response.
  * Encrypting sensitive data: Ensuring that data at rest is encrypted to mitigate exposure in case of a breach. While this might not fix the original problem, it makes the risk less of a problem.
* **Pros:** Reduces potential damage and buys time for a long-term solution.
* **Cons:** Does not completely eliminate the risk.
* **Best for:** Medium and Low severity issues

### 4. Accept the Risk (Document and Monitor It)

* Used when the risk is low or the cost of fixing it is too high or when business needs outweighs a security risk.
* Examples:
  * Low-risk vulnerabilities in non-critical systems: A minor vulnerability in an internal tool used by a small team with no sensitive data exposure.
  * Legacy systems with limited exploitation potential: If a system is air-gapped or has sufficient compensating controls, fixing certain vulnerabilities may not be necessary.
  * Compensating for vulnerabilities with external controls: If a known issue in a component cannot be fixed, a security team may choose to accept the risk but mitigate its impact by monitoring and restricting access.
* **Pros:** Saves resources for more critical vulnerabilities.
* **Cons:** Must be carefully evaluated and monitored.
* **Best for:** Low-severity issues

***

## The Benefits of Treating Vulnerabilities as Risks

#### 1. Prioritization of Critical Issues

* Instead of addressing every vulnerability, teams can focus on high-impact and high-likelihood threats first.
* Example: Prioritizing an exposed database vulnerability over a minor UI security issue.

#### 2. Faster, More Effective Remediation

* Security teams can allocate resources efficiently by choosing the right approach (fix, mitigate, delegate, or accept).
* Example: Instead of spending months fixing a low-risk issue, a compensating control (like a WAF) might reduce risk instantly.

#### 3. Alignment with Business Strategy

* Risk-based decision-making ensures security efforts align with business priorities.
* Example: A company focused on compliance may prioritize fixing vulnerabilities affecting regulatory requirements.

#### 4. Clearer Communication with Stakeholders

* Security leaders can frame issues in terms of business risk when communicating with upper management or other stakeholders rather than just "fixing bugs".&#x20;
* Example: Presenting a vulnerability’s risk in financial terms helps executives make informed decisions.

***

### Conclusion

Viewing vulnerabilities as business risks—not just software defects—leads to better decision-making, faster remediation, and more strategic security efforts. Rather than defaulting to "fix everything," technical leaders can apply the most efficient risk response strategy:

✅ Eliminate high-risk vulnerabilities where possible.\
✅ Delegate security responsibilities when feasible.\
✅ Mitigate risks using compensating controls.\
✅ Accept low-impact risks with proper documentation.

This approach ensures smarter resource allocation, stronger security posture, and better business outcomes. Next time a vulnerability report arrives, ask: What’s the best way to manage this risk?


# Part 3: Getting the Most Out of Software Secured

### The Engineering Team’s Challenge

If you are leading a team of engineers, you face a constant battle: balancing feature development with securing your applications. Vulnerability remediation can be particularly challenging due to:

* Large security reports that could be difficult to prioritize.
* Coordination challenges between security and engineering teams.
* The risk of security issues slipping through the cracks.
* The challenge of estimating remediation time.
* Balancing security with business needs.
* Making the most of their security budget.

Software Secured simplifies this process with real-time support, a [collaborative dashboard](https://app.storylane.io/share/t6tzugrvxjs0), and expert guidance to help your team remediate vulnerabilities efficiently.

***

## How Software Secured Accelerates Vulnerability Remediation

### 1. Direct Access to Security Experts via Slack

Your engineers don’t have to wait days for security guidance. With Software Secured’s Slack support, they get real-time answers from our security experts.

* Quick clarifications on vulnerability reports.
* Guidance on remediation approaches while coding.
* Faster issue resolution by reducing back-and-forth email exchanges.

***

### 2. Expert-Led Meetings for Clearer Remediation Plans

We don’t just find vulnerabilities – we help you fix them efficiently.

* Post-test readout meetings to walk through the whole report.
* Personalized developer sessions to ensure fixes are both effective and long-lasting.
* Alternative remediation strategies and tailored solutions for your unique needs.

***

### 3. A Centralized Portal for Tracking and Managing Vulnerabilities

Software Secured’s [Portal Dashboard](https://app.storylane.io/share/t6tzugrvxjs0) provides a single source of truth for your security findings.

* View and manage vulnerabilities across multiple projects in real time.
* Triage your vulnerabilities using Add Notes and Labels to assign ownership and track remediation progress.
* Monitor SLAs and deadlines to ensure vulnerabilities are fixed on time without missing an SLA.

***

### 4. Seamless JIRA\* Integration for Developer-Friendly Workflow

Security shouldn’t be a separate workflow. Software Secured integrates directly with JIRA to streamline vulnerability tracking.

* Push vulnerabilities into JIRA as development tickets.
* Keep track of remediation status without switching between tools.
* Automate security fixes into the development cycle so engineers treat them like any other ticket to be closed.

\*JIRA integration is available only in select packages. Talk to [our sales team](https://www.softwaresecured.com/book-a-consultation) to explore adding JIRA integration to your package.

***

### 5. Deep Security Expertise with Actionable Insights

Software Secured isn’t just another pentesting provider – our team is made up of full-time, Canada-based security professionals with deep expertise in SaaS and cloud security.

* Manual, high-quality security testing with no false positives.
* Clear, detailed remediation steps tailored to your codebase.
* Guidance aligned with compliance frameworks like SOC 2, ISO 27001, and PCI.
* Hands-on developer training to build a culture of secure coding. \*

\* Developer training is available in full day and 2 hour format. Please visit our[ Pricing Page](https://www.softwaresecured.com/pricing) and reach out to [our sales team](https://www.softwaresecured.com/book-a-consultation) to learn more.&#x20;

***

### Why Engineering Leaders Choose Software Secured

Unlike traditional penetration testing firms that just deliver a report, we partner with your team to make security remediation practical, actionable, and efficient.

#### Key Differentiators

✔ Slack support – no waiting for email responses.&#x20;

✔ Collaborative portal – track, label, and prioritize vulnerabilities.&#x20;

✔ Seamless JIRA integration – integrate security directly into development.&#x20;

✔ Hands-on remediation support – expert-led meetings and guidance.&#x20;

✔ Developer enablement – training and mentorship to improve security skills.&#x20;

✔ Actionable, zero-false-positive findings – high-quality manual testing.

By partnering with Software Secured, you empower your team to fix security issues faster, improve developer security knowledge, and maintain compliance – all while keeping your product roadmap on track.

## Summary:

By working with Software Secured, you get more than a pentest – you get a dedicated security partner committed to making your development process safer, faster, and more efficient.

✔ Faster remediation with real-time Slack support and expert-led guidance.&#x20;

✔ Improved team collaboration with a centralized security portal.&#x20;

✔ Integrated security workflows through JIRA and developer-friendly tools.&#x20;

✔ Long-term security maturity with ongoing assessments, training, and compliance support.

For VPs of Engineering looking to streamline security without slowing down development, Software Secured provides the perfect balance of expertise, automation, and hands-on support.

***

## Beyond Fixing Vulnerabilities&#x20;

### How Software Secured Helps You Stay Secure for the Future

Security is not just about fixing today’s issues – it’s about preventing future risks. Software Secured offers a comprehensive security partnership that extends beyond penetration testing.

#### There are several ways to take your security to the next level:

* Quarterly security testing ([PTaaS model](https://www.softwaresecured.com/service/penetration-testing-as-a-service)) to uncover risks continuously.
* [Secure code reviews](https://www.softwaresecured.com/service/secure-code-review) to prevent vulnerabilities before they reach production.
* [Cloud security reviews](https://www.softwaresecured.com/service/secure-cloud-review) to identify misconfigurations.
* [Compliance readiness](https://www.softwaresecured.com/post/do-you-need-penetration-testing-for-compliance) for SOC 2, ISO 27001, and more.
* [Developer training](https://www.softwaresecured.com/service/threat-modelling) to build secure coding expertise within your team.
* Ongoing consultation beyond just test results, supporting your security journey year-round. This is included with quarterly PTaaS packages. Security Consultations are used for:
  * Review new features and security controls to be implemented.
  * Threat model new features/components.
  * Review fixes to vulnerabilities from the pentest report prior to implementation.
  * Review of third-party reports (including bug bounties or external researcher reports).
  * Consult on application and network security questions from stakeholders or customers.

[Talk to us](https://www.softwaresecured.com/book-a-consultation) if you want more information about these services.