1. Parties Involved
This policy applies to all existing and potential: Builder.ai employees, 3rd parties, vendors, and Customers, trainees or other such authorised persons that Builder.ai may interact with in the course of delivering its products and services.
1.1 Builder
Builder.ai is the primary party to which this policy applies. Every Employee or Subcontractor is subject to this policy.[a]
1.2 Cloud Providers
Builder partners with industry-leading Cloud Providers to deliver products and services. Builder vets these Providers to ensure they meet the highest standards of security for Customers.
Builder’s Cloud Providers include but are not limited to:
- Amazon Web Services
- Microsoft Azure
- Digital Ocean
1.3 Customers
Builder's Customers are a major part of Security and are encouraged to follow best practices in accordance with this policy at all times.
2. Security Policy
Builder takes responsibility for the security of workloads running on all of their approved Cloud Providers. This includes protecting: all instances, applications, SaaS-based services, and all forms of credentials. This is by no means an exhaustive list of the tools, services or infrastructure that Builder takes responsibility for.
In addition, Builder is mindful of general best practices around security and augment their Cloud Provider offerings with the best in class third-party solutions where appropriate.
2.1 General Best Practices
These practices will help build a secure computing environment.
- Maintain the confidentiality, integrity and availability of Customer data and business assets.
- Managing customer assets in a mutually agreed manner.
- Ensuring all information assets are protected against unauthorised access.
- Develop and maintain a robust risk assessment, management and treatment method.
- Apply and enforce appropriate risk controls at all times.
- Develop and maintain a business continuity plan to ensure agreed services for a Customer as per published and agreed Service Level Agreements (SLA).
- Investigate all security incidents in line with Builder’s Security Management Process and ensure that all information about incidents is captured, and made available through suitable Incident Management Software.
- Security-related information is made available to all appropriate stakeholders and summary updates are provided at regular intervals.
- Encourage & enforce security best practices for all employees, associates and third parties at all times.
2.2 Well-Architected Framework
Builder subscribes to the AWS and Azure Well-Architected frameworks as driving design principles for the creation of tools and services. These include:
- Implementing a strong identity foundation around the principle of least privilege.
- Enabling traceability with real-time monitoring and alerting.
- Applying security at all layers.
- Automating security best practices with controls defined in code.
- Protecting data in transit and at rest.
- Keeping people away from data by minimising the need for direct access.
- Preparing for security incidents by having a comprehensive Incident Management Process.
The items listed above are grounding principles as the frameworks are much broader than are outlined above. Please review the published documentation on these frameworks for a more comprehensive breakdown of their contents.
- https://aws.amazon.com/architecture/well-architected
- https://learn.microsoft.com/en-us/azure/architecture/framework/
2.3 Policy updates
This document will be reviewed monthly by a nominated set of Builder’s technical leadership. This group will be referred to as the Security Review Board.
As part of this review process, any risks identified as per ongoing efforts to maintain and enhance security, customer feedback or security incidents may lead to updates to this policy.
All changes to the document should be supplied to the Security Review Board before the monthly meeting where they will be reviewed and approved.
2.4 Revision History
Builder will maintain named versions of this document for each change using the format major.minor:
Drafts will increment the minor version number: 0.1, 0.2
Final document will increment the major number: 1.0, 2.0
This will be implemented by creating a “named version” in the version history of the document.
3. Security Awareness
Builder performs security awareness at two levels:
3.1 Organisational Awareness
- Comprehensive induction programmes
- Annual security focussed training
- Visible security posture via appropriate reports and dashboards
- Open access to this policy and other security-related documentation
- Visible physical security measures
- Active device policies and management
- Fire drills
3.2 Customer Awareness
- Client onboarding package that details our security protocols and best practices.
- Education and awareness are spread through blogs, whitepapers, and quarterly recommendations shared with Customers to enhance their infrastructure performance and security
- Builder shares information from its Cloud Providers about best practices with their managed service Customers periodically.
- Builder conducts workshops for Customers to make them aware of security risks and best practices.
- Secret shopper testing is conducted annually by Builder. To verify that appropriate actions are performed to authenticate the user. As detailed in the on-call procedures document link
This is not an exhaustive list and Builder continually reviews the practices it undertakes to promote security awareness.
3.3 Recommendations to all parties:
Builder updates all parties regarding security awareness, related to all aspects of security including the steps needed to maintain a high standard of security when using products and services.
- All services must only be publicly accessible via a Firewall. Only those ports deemed to be necessary for the running of a provided service or product should be opened on the firewall. Typically this will include, but not be limited to ports 80 & 443. Opening ports to the public should only be done following an appropriate security evaluation. Access to any other ports should only be made available within the private network in which their product or service will have been provisioned
- If external access is required to the private network in which products and services are running then a secure Bastion should be used at all times to mitigate any risk of unauthorised access.
- Ensure that all forms of credentials are kept securely, such as in a password manager. Passwords must not be shared with any parties. Passwords must be of a level of complexity to prevent Brute Force attacks.
- Ensure that appropriate tools, such as Network Access Control Lists (NACL), are in place and configured to manage the flow of traffic and prevent unauthorised access across the networks being used, both public and private.
- Ensure that all communication between services when transferring data is done securely, via a private network connection, using appropriate tools to the relevant Cloud Provider.
- Use a secure Virtual Private Network (VPN) connection to transfer all data into any services or products hosted by Builder’s Cloud Providers.
4. Classification of Data
Builder enforces a consistent method of data classification. This ensures security and integrity when being handled by any appropriate party. The documents and data that need to be protected are classified under the following categories:
Classification | Description |
Confidential | The data is highly sensitive and is kept segregated and secure within the infrastructure. Access to data is restricted to only specific individuals that have a valid need for access, e.g the chairman of a board of directors may access sensitive data regarding business operations that could affect share values |
Restricted | The data is sensitive and is kept segregated and secure within the infrastructure. Access to this data is restricted to only individuals where their role dictates that access is essential in the performance of their duties, e.g a member of a Human Resources team may only access information regarding an employee's remuneration. |
Private | The data is considered sensitive and is kept securely within the infrastructure. Access to this data is restricted to authorised parties only. It may be shared by authorised parties with other parties but is never made available to the public, e.g a digital company handbook detailing how to securely connect with with systems is shared by employees with approved 3rd party vendors |
Public | The data is not considered sensitive and is available to be openly shared with any parties and members of the public e.g this document is available via https://www.builder.ai/terms/security-policy-document and can be shared by anyone to anyone |
5. Network Security (Firewalls)
Builder's Cloud Providers offer firewall services for securing cloud-based servers. These are always implemented as part of the hosted infrastructure provided as part of any products and services.
Builder's services and infrastructure are protected by one or more firewall services that implement rules specifying the type of network traffic that is permissible for a given service.
At a higher level, Builder also applies network access controls on the load balancers and the private networks in which all services and products are housed.
By default, the firewalls operate in a “deny-all” mode and Customers must explicitly open any required ports needed to allow inbound traffic. Builder recommends that all parties apply a restrictive firewall policy and only allow communication that is required.
6. Denial of Service/Distributed Denial of Service (DoS/DDoS) Mitigation
Builder's Cloud Providers offer an array of tools that enable us to implement comprehensive DDoS mitigations. Builder works closely with all Builder’s Cloud Providers and Infrastructure partners to proactively monitor these kinds of events, and where identified apply appropriate measures to stop or mitigate them.
7. Port Scanning
Port scanning is prohibited across Builder’s networks and they actively monitor for such activity. Builder works closely with Cloud Providers to investigate every reported instance. When port scans are detected, they are stopped and access is blocked.
8. Antivirus and Anti-Malware
Builder deploy antivirus/anti-malware solutions, where appropriate, to protect all infrastructure, hosted applications & services and data belonging both to Builder and Customers. It is recommended that Customers deploy suitable anti-virus solutions to protect their systems from virus and malware threats.
9. Identity Access Management
Builder enforces strict Access Management Controls for all internal services and products. This is done to protect against any unauthorised access to systems and those belonging to Customers or partners.
Builder operates on a Zero trust model and will only provide access on a least-privilege basis to requested services.
9.1 Cloud Provider Access
Identity Access Management includes access controls to any of the Cloud Providers Builder utilise. Access to these services is strictly controlled and monitored to ensure only authorised personnel and systems can interact with systems and services essential to their function.
9.2 Multi-Factor Authentication (MFA)
All systems require Multi-Factor Authentication (MFA) to validate the authenticity of any individual.
9.3 Credential Management
Individuals accessing systems and services are required to follow good security practices in the creation and management of Credentials.
Policies will be determined for individual systems and enforced accordingly.
Examples of criteria for the creation and enforcement of credentials include:
- Credentials should be updated regularly, with a maximum of 90 days between changes
- Credentials should be unique for every system used
- When updating a credential, an individual should not reuse a historical credential
- Credentials should be a minimum of 10 characters in length
- Credentials should be of sufficient complexity to reduce the risk of brute force or dictionary attacks. They should contain a combination of upper and lower case letters, numbers and punctuation marks or special characters.
9.4 Protective Measures
- Strong Identity Access Management protocols are enforced at all times for both humans and software applications, including any “Intelligent” applications utilising Artificial Intelligence.
- All access is defined via Roles and is never attached to individuals directly.
- Access to a “root” or “admin” user is restricted at all times for any form of operational activity.
- Dedicated Service Accounts are provisioned for all internal resources to facilitate auditing and the management of permissions for that resource.
- All Service accounts require secure key exchanges to authenticate with any given resource.
- Credentials used to authenticate are never shared with anyone and steps are taken to ensure that these cannot be exposed accidentally.
- Where possible a Single Sign On (SSO) mechanism will be employed to ensure access management occurs in as few places as possible to reduce maintenance and attack surfaces.
- Auditing of access to resources and information is enabled at all times.
10. Data Security
Access to information shall be restricted to only authorised users who have a required business need to access the information. This access will be audited and tracked by internal systems to ensure that unauthorised access does not take place.
In the case of access to a customer's data, authorization must be granted by a suitably authorised person from within the customer's business. Builder will only provide access upon request by an authorised person using their secure support portal. Requests made via email, telephone or other such mechanisms are considered insecure and will not be actioned.
10.1 Encryption
Data will be encrypted at all times, both “in-Transit” and “at-Rest” on all internal systems, devices and networks.
Builder will ensure appropriate software is installed on all systems to maintain the integrity and security of any data housed on them.
In the event of data being stored or accessed on portable devices, these devices will be fully encrypted requiring appropriate biometric or credential-based authentication. These devices will be subject to appropriate remote device management, enabling the locking and/or erasure of data to protect against loss or theft.
10.2 Key Management Services
Where appropriate Builder will use Key Management Services offered by one of Builder’s Cloud Providers to securely store and manage the Cryptographically Secure Keys that are created to enable Encryption-at-Rest and Encryption-in-Transit for all data.
10.3 Backup and Retention
To prevent accidental or intentional loss or deletion of data, Builder performs frequent periodic backups. In the event of an incident that results in the loss of data, Builder can restore data from these backups.
The schedule of backups will vary according to the sensitivity of the data and any defined Customer requirements.
Backups are always kept in a specifically designated location away from the application or Data Store, both logically and geographically, to prevent any contamination or loss.
The period of Retention for backups varies depending on the nature of the data and any specific agreements that may have been made with a customer. Retained data is always held per Data Protection legislation that has jurisdiction over said data.
11. Logs
Builder maintains several types of logs in the delivery of it’s services. There are two primary use cases for logs:
- Operational Logs
- Audit Logs
Logs are stored securely in encrypted locations, typically with one of Builder’s Cloud Providers, and subject to the defined Identity Access Management controls.
Periodic analysis of all logs is undertaken to ensure appropriate controls are in place and no unauthorised access has taken place.
Builder will use logs to build and implement threat modelling tools to identify systematic attacks against all internal and customer systems
11.1 Retention
All logs follow strict retention policies that are operated per any Data Protection legislation that may have jurisdiction and a Customer's business needs.
Builder may, where appropriate, retain logs for up to a maximum of 455 days. Following a period of 90 days, all logs will be transferred from encrypted standard storage to an encrypted long-term storage location.
11.2 Personally Identifiable Information
Builder endeavours to avoid the capture of Personally Identifiable Information in all forms of logs. Any logs that may include Personally Identifiable Information are kept strictly per Data Protection legislation compatible with their operations. These include, but are not limited to; GDPR, APA, PIPL, ADPPA, etc.[b]
If it becomes necessary to retain logs that contain Personally Identifiable Information, beyond the scope of applicable legislation, Builder will anonymise any such information before the expiration of any time limits defined in the given legislation.
12. Disaster Recovery
Builder takes the responsibility of Disaster Recovery procedures very seriously and maintains detailed Disaster Recovery Plans covering a multitude of scenarios for all systems and services they manage and maintain.
12.1 Internal systems
All internal systems are built to be resilient and include redundancy features to reduce the impact of a wide range of disaster scenarios. However, if these features are not able to compensate, Builder has compiled several operational plans for each system to allow us to quickly resolve and bring services and systems back online. These plans include the creation and implementation of tooling specifically to assist in the restoration of services.
These plans may contain sensitive information about systems and security and thus are only available on request.
12.2 Customer environments
All hosted Customer environments receive the same treatment as Builder’s internal systems. Builder also provides tailored plans to Customers that may have specific requirements beyond those offered by default.
12.3 Business Continuity Tests
Periodically Builder will perform continuity tests to validate that Disaster Recovery procedures are appropriate to all parties needs. This involves Builder simulating disaster scenarios. These tests can occur in both test and production environments, according to the nature of the tests being undertaken and the resilience expected of a given system.
These tests occur a minimum of once every 12 months. The results of these tests are then reviewed and used to ensure that plans and scenarios are appropriate to both Builder’s and the Customer’s needs.
12.4 Support
Builder provides support 24 hours a day to ensure that, should a disaster scenario occur, they can respond rapidly to address a given scenario.
13. Vulnerability Scanning & Testing
Builder performs vulnerability scanning & testing on all of the products and services it provides to Customers.
Upon identification of vulnerabilities they will be classified and prioritised and then have appropriate mitigation or resolution applied.
Identification techniques include but is not limited to;
13.1 Static Application Security Testing (SAST)
Builder undertakes to employ SAST on all source code, both proprietary and open-source, developed or implemented, prior to its deployment into an environment, be it production or otherwise.
13.2 Dynamic Application Security Testing (DAST)
Builder undertakes to employ DAST on all source code, both proprietary and open-source, developed or implemented, immediately following its deployment onto an non-production environment. It will also look to perform DAST periodically upon production or production-like environments, this allows the capture of vulnerabilities that have not yet been identified
13.3 Penetration Testing
Builder undertakes to employ Penetration Testing on all production environments. It aims to provide a significant level of automated penetration testing against non-production or production environments post deployment of an application of infrastructure, on a regular basis.
Builder's internal systems will be subject to annual Penetration Testing by an external Penetration Testing company for auditing purposes. Should a customer wish to engage their own Penetration Testing, Builder will work with the Customer and/or a nominated Penetration Testing company to achieve this.
13.4 Infrastructure Scanning
Upon deployment of any Infrastructure, Builder will initiate a scan of it to identify known vulnerabilities.
Builder will work with Cloud Providers to enable active infrastructure scanning tools in both production and non-production environments to allow rapid identification and resolution of vulnerabilities within its infrastructure.
13.5 Load testing
Builder provides SLAs around the capacity of its products and services. These SLAs are regularly tested in production-like environments to ensure their accuracy and provide assurance and security of those guarantees.
Builder will only perform Load Testing upon specifically designated production-like systems so as not to impact the operation of production systems. In the event that a Customer wishes to perform Load Testing upon a production environment, Builder reserves the right to waive all guarantees defined in SLAs for the period in which a said Load testing takes place.
14. Responsibilities and Rights
Responsibility for the physical and information security within networks, systems and services, rests with Builder.
Builder waives any responsibility for Information, intentionally or accidentally, published by a Customer, with public visibility, on a system or service provided by Builder.
Customers accept responsibility for information uploaded to any systems or services that they may be subscribed to.
Builder and its employees shall comply with this Security Policy and associated procedures, including the maintenance of data confidentiality and integrity. Failure to comply may result in disciplinary action on the part of the Employee
All Builder resources are under strict Non-disclosure Agreements.
Appendix A
Glossary of Terms
Term | Definition |
Customer | An individual or business that purchases products and services from Builder |
Cloud Provider | An organisation that provides Infrastructure as a Service and Software as a Service. |
Infrastructure as a Service (IaaS) | Infrastructure is provided by an organisation where the implementation is handled by the said organisation and the resulting infrastructure is made available to Builder for use. |
Software as a Service (SaaS) | is provided by an organisation where the implementation is handled by the said organisation and the resulting Software is made available to Builder for use. |
Identity & Access Management | A framework for providing identification of approved entities and their permission to access given systems and services in an authorised manner. |
Multi-Factor Authentication | A security mechanism that requires an entity to validate its identity using a workflow that may involve multiple checks |
Service Level Agreements (SLA) | An agreement made between two parties that define the level of service to be guaranteed and the timescales for remediation of any incidents that may impact the delivery of that service. |
Incident Management Software | Software that provides a centralised location to store and categorise information about incidents and provides tools to assist with the capture of information about a given incident. |
Incident Management Process | The process by which Builder endeavours to investigate all incidents, capture information, provide root cause analysis and execute any actions or remediation required to prevent similar incidents from occurring. |
Security Review Board | A group of industry specialists within Builder that have been nominated to act as a group to ensure security policies are managed and maintained appropriately. This group may include Employees with Builder or other suitably qualified stakeholders. |
Bastion | A secure service or piece of infrastructure that acts as a secure entry point for accessing a private network, typically via secure tunnelling protocol |
Firewalls | A network security device that monitors incoming and outgoing network traffic and permits or blocks data packets based on a set of security rules. Its purpose is to establish a barrier between an internal network and incoming traffic from external sources (such as the internet) in order to block malicious traffic like viruses and hackers. |
Denial of Service (DoS) | A denial-of-service (DoS) attack is a type of cyber attack in which a malicious actor aims to render a computer or other device unavailable to its intended users by interrupting the device's normal functioning. DoS attacks typically function by overwhelming or flooding a targeted machine with requests until normal traffic is unable to be processed, resulting in denial-of-service to additional users. A DoS attack is characterised by using a single computer to launch the attack. |
Distributed Denial of Service (DDOS) | A distributed denial-of-service (DDoS) attack is a malicious attempt to disrupt the normal traffic of a targeted server, service or network by overwhelming the target or its surrounding infrastructure with a flood of Internet traffic. DDoS attacks achieve effectiveness by utilising multiple compromised computer systems as sources of attack traffic. Exploited machines can include computers and other networked resources such as IoT devices. |
Port Scanning | Port scanning is a method of determining which ports on a network are open and could be receiving or sending data. It is also a process for sending packets to specific ports on a host and analysing responses to identify vulnerabilities. |
Virus & Anti-virus | A computer virus is a type of malicious code or program written to alter the way a computer operates and that is designed to spread from one computer to another. A virus operates by inserting or attaching itself to a legitimate program or document that supports macros in order to execute its code. In the process a virus has the potential to cause unexpected or damaging effects, such as harming the system software by corrupting or destroying data. |
Malware & Anti-malware | Malware (short for “malicious software”) is a file or code, typically delivered over a network, that infects, explores, steals or conducts virtually any behaviour an attacker wants. And because malware comes in so many variants, there are numerous methods to infect computer systems. Though varied in type and capabilities, malware usually has one of the following objectives:
|
Identity Access Management | Identity and access management (IAM) is a set of processes, policies, and tools for defining and managing the roles and access privileges of individual network entities (users and devices) to a variety of cloud and on-premises applications. Users include Customers, partners, and employees; devices include computers, smartphones, routers, servers, controllers and sensors. The core objective of IAM systems is one digital identity per individual or item. Once that digital identity has been established, it must be maintained, modified, and monitored throughout each user’s or device’s access lifecycle. |
Service Account | A service account is a digital identity used by software or service to interact with other applications or the operating system. They are often used for machine to machine communication (M2M), for example for application programming interfaces (API). The service account may be a privileged identity within the context of the application. |
Single Sign-on (SSO) | Single sign-on (SSO) is an authentication scheme that allows a user to log in with a single ID to any of several related, yet independent, software systems. |
Multi-Factor Authentication (MFA) | Multi-factor Authentication (MFA) is an authentication method that requires the user to provide two or more verification factors to gain access to a resource such as an application, online account, or a VPN. MFA is a core component of a strong identity and access management (IAM) policy. Rather than just asking for a username and password, MFA requires one or more additional verification factors, which decreases the likelihood of a successful cyber attack. |
Data-in-Transit Encryption | Data in transit, or data in motion, is data actively moving from one location to another such as across the internet or through a private network. Data protection in transit is the protection of this data while it’s travelling from network to network or being transferred from a local storage device to a cloud storage device. Wherever data is moving, effective data protection measures for in-transit data are critical, as data is often considered less secure while in transit. Builder recommends all data in transit be encrypted over a protocol such as SSL/TLS. |
Data-at-Rest Encryption | Data at rest is data that is not actively moving from device to device or network to network, such as data stored on a hard drive, laptop, or flash drive, or archived/stored in some other way. Data protection at rest aims to secure inactive data stored on any device or network. While data at rest is sometimes considered to be less vulnerable than data in transit, attackers often find data at rest a more valuable target than data in motion. Builder recommends encrypting sensitive data at rest. |
Key Management Service | A key management service (KMS) is a system for securely storing, managing, and backing up cryptographic keys. Of course, the specific types of keys that each KMS supports vary from one platform to another. Most key management services typically allow you to manage one or more of the following secrets:
|
Cryptographically Secure Keys | In cryptography, a key is a string of characters used within an encryption algorithm for altering data so that it appears random. Like a physical key, it locks (encrypts) data so that only someone with the right key can unlock (decrypt) it. |
Data Store | A data store is a repository for persistently storing and managing collections of data which include not just repositories like databases, but also simpler store types such as simple files, emails, etc. |
Backup | A backup is a copy of computer data taken and stored elsewhere so that it may be used to restore the original after a data loss event. |
Retention | Retention, or A backup retention policy, is an internal organisational rule that determines what data the organisation keeps, where it keeps the data and how long it keeps the data. Retention policies may indicate the types of backup that are acceptable. |
Operational Logs | When an operation is executed, an operation log is generated. An operation log contains information about when and where an operation ran, the operation status, the number of source and target records processed, and any log messages. Whether detailed log messages are displayed depends on permission and access levels. |
Audit Logs | Audit logging is the process of documenting activity within the software systems used across an organisation. Audit logs record the occurrence of an event, the time at which it occurred, the responsible user or service, and the impacted entity. All of the devices in a network, cloud services, and applications emit logs that may be used for auditing purposes. A series of audit logs is called an audit trail because it shows a sequential record of all the activity on a specific system. By reviewing audit logs, systems administrators can track user activity, and security teams can investigate breaches and ensure compliance with regulatory requirements. Audit logs help organisations document a historical record of activity for compliance purposes and other business policy enforcement. |
Personally Identifiable Information (PII) | Personally Identifiable Information (PII) is a legal term pertaining to information security environments. While PII has several formal definitions, generally speaking, it is information that can be used by organisations on its own or with other information to identify, contact, or locate a single person, or to identify an individual in context. |
Disaster Recovery | is an organisation’s ability to restore access and functionality to IT infrastructure after a disaster event, whether natural or caused by human action (or error). DR is considered a subset of business continuity, explicitly focusing on ensuring that the IT systems that support critical business functions are operational as soon as possible after a disruptive event occurs. |
Test Environment | A test environment is where the testing teams analyse the quality of the application/program. This also allows computer programmers to identify and fix any bugs that may impact smooth functioning of the application or impair user experience. |
Production Environment | A production environment is where the primary instance of an application operates in order to conduct essential business operations |
Static Application Security Testing (SAST) | Static application security testing (SAST) is a set of technologies designed to analyse application source code, byte code and binaries for coding and design conditions that are indicative of security vulnerabilities. SAST solutions analyse an application from the “inside out” in a non running state. |
Dynamic Application Security Testing (DAST) | Dynamic application security testing (DAST) technologies are designed to detect conditions indicative of a security vulnerability in an application in its running state. Most DAST solutions test only the exposed HTTP and HTML interfaces of Web-enabled applications; however, some solutions are designed specifically for non-Web protocol and data malformation (for example, remote procedure call, Session Initiation Protocol [SIP] and so on). |
Penetration Testing | Penetration testing goes beyond vulnerability scanning to use multi step and multi vector attack scenarios that first find vulnerabilities and then attempt to exploit them to move deeper into the enterprise infrastructure. Since this is how advanced targeted attacks work, penetration testing provides visibility into aggregations of misconfigurations or vulnerabilities that could lead to an attack that could cause serious business impact. As a minimum, penetration testing provides a means for prioritising the highest risk vulnerabilities. |
Infrastructure Scanning | Infrastructure scanning is the process of performing an automated series of checks against an infrastructure target or range of targets, in order to detect whether there are any security vulnerabilities that are potentially exploitable. |
Load Testing | Load testing places a simulated “load” or demand on a web application to ensure it remains stable during operation. During a load test, testing software will measure the capacity of a web application via transaction response times. If an app features extended response times or becomes unstable at a certain level of simulated traffic, the software will have likely reached its peak operating capacity—which means a solution to this software bottleneck needs to be addressed and implemented. |
Facebook
X
LinkedIn
YouTube
Instagram
RSS
