> For the complete documentation index, see [llms.txt](https://docs.softwaresecured.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.softwaresecured.com/checklist/infrastructure-summary.md).
# Infrastructure summary
space.vars.company\_name 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.
***
### :globe-pointer: 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.
***
### :network-wired: Internal Network Pentest
#### 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.md) page.
{% 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.
***
### :chart-network: 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.
***
### :cloud: 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).
#### 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.
***
### :square-code: 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 ([@SoftwareSecuredOperations](https://github.com/SoftwareSecuredOperations) on GitHub) or by sending us the source code directly.
{% hint style="success" %}
To send us the code directly, upload it to the [Pentest checklist](/checklist/pentest-checklist.md) in space.vars.product\_name.
{% endhint %}
***
### :mobile: 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.
#### 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.md).
Another binary-sharing method is to give space.vars.company\_name CI/CD access; however, this method is not as streamlined as using the checklist.
Providing CI/CD access to space.vars.company_name
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.
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.
Grant access to the following email address:
#### 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.
#### 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.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.softwaresecured.com/checklist/infrastructure-summary.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.