Validation checks
Reference the validation checks performed by the Demisto SDK validate command.
BA: Basic
BA100
Validates Marketplace content is set to -1 to make it easier to distinguish it from modified, versioned content.
The version for system content items should always be -1 as per the standard.
Yes
BA101
Validates the file ID and name fields are identical.
The ID attribute serves as the unique identifier for files across the platform
Yes
BA105
Validates the content item ID doesn't include any slashes (/).
IDs with slashes are not allowed in the platform
Yes
BA106
Validates the item's fromversion field is sufficient.
Ensures content can use the latest and greatest features of the platform. The minimal value is the third-last platform release version.
Yes
BA108
Checks if there are separators in the folder name.
Ensures consistent, readable folder structures by avoiding separators like spaces, underscores, or hyphens.
BA109
Checks if there are separators in the script or integration files names.
Ensures filenames for scripts and integrations do not contain separators to maintain consistency and readability.
BA110
Checks that the entity name or display name does not contain the entity type.
Improves clarity and simplicity in the content repository.
BA111
Checks whether the name of a content item contains an excluded word.
Increases clarity by keeping content names simple.
BA113
Checks for content item names with trailing spaces.
Ensures accurate referencing.
Yes
BA114
Checks that a content item from one pack to another.
Ensures content items are not moved from one pack to another.
BA116
Validates the CLI name and the ID match for incident and indicator fields.
Ensures consistency between the CLI name (used by the platform) and the ID.
Yes
BA118
Validates the item's toversion is greater than or equal to its fromversion.
Content with a from_version greater than the to_version will not show in the platform.
Yes
BA119
Validates the Python file doesn't have a copyright section with the words BSD, MIT, Copyright, or proprietary.
Content in Marketplace is licensed under the MIT license.
BA124
Validates the script/integration has a unit test file.
Unit tests ensure code behaves consistently between versions.
BA125
Checks that customer facing docs and fields don't contain internal terms.
Ensures customer-facing docs avoid internal terms for clarity.
BA126
Checks if script/integration is deprecated correctly.
Deprecated scripts / integrations need clear descriptions for user guidance.
BA127
Validates the level of depth of the context output path in the YAML is less than or equal to 5.
Ensures avoiding overly nested context to ease data extraction.
BC: Backward compatibility
BC100
Validates the pack name subtype of the new file matches the old one.
Changing subtype can break backward compatibility.
Type indicates the language your integration is written in. Cortex XSOAR and Cortex XSIAM currently support Python and JavaScript. When using Python, you must specify the subtype field (either: python2 or python3). Additionally, when using Python dockerimage should be specified. If dockerimage is not specified, a default Python 2 image will be used.
Yes
BC101
Checks whether context output keys were removed from the script's output section.
To verify we don't break backward compatibility.
BC102
Checks whether the context path changed.
Changing the paths may break dependent content items which rely on the existing paths.
BC103
Checks whether an argument name changed.
If an existing argument is renamed, it will break backward compatibility.
BC104
Checks whether a command name or argument name changed.
If an existing command or argument is renamed, it will break backward compatibility.
BC105
Checks whether the ID of a content item changed.
Changing the ID of an item causes it to show as a new item in the platform, and to not update properly for users who already have a previous version installed.
Yes
BC106
Checks whether the fromversion property changed on existing content files.
Changing the fromversion field for a content item can break backward compatibility.
The last section of a YAML file provides information regarding what version is supported and tests.
fromversion indicates the server version that is supported with the integration. If the server version is below the fromversion, the integration will not display in the Settings area.
BC107
Checks whether the toversion property changed on existing content files.
Changing the toversion field for a content item can break backward compatibility.
BC108
Checks whether the marketplaces property was removed or added in a manner that effectively removes all others.
Removing marketplaces or adding a new one that effectively removes all others can cause issues with the content item's visibility and availability.
BC110
Checks whether new required arguments were added to an existing command.
Adding a new argument to an existing command and defining it as required or changing a non-required argument to required breaks backward compatibility.
BC111
Checks whether new required arguments were added to an existing script.
Adding a new required argument or changing a non-required one to required without specifying a default value breaks backward compatibility.
BC112
Checks whether parameters were removed from an existing integration.
Removed parameters can cause errors if the parameter is needed by the server or integration code.
BC113
Checks whether incident types were removed and incident fields changed.
Ensures no breaking changes are made to existing mappers so customers won't lose data between pack updates.
BC114
Checks whether a pre-defined list of fields was removed or modified in the integration YAML.
Ensures backward compatibility between different versions of a content item.
CL: Classifier
CL100
Validate that a classifier has a type = classification field.
This standardization is for the platform to correctly identify and handle the classifier.
Yes
CR: Correlation rule
CR102
Validates search_window exists and is non-empty for execution_mode = SCHEDULED.
SCHEDULED execution must have a defined time frame search_window to operate within.
DA: Dashboard
DA100
Validates the dashboard excludes all the nonrequired fields.
The dashboard should contain only the required fields.
Yes
DA101
Validates the dashboard includes all the required fields.
The dashboard should contain the required fromDate, toDate, and fromDateLicense fields.
DO: Docker image
DO100
Validates the given content item does not use the tag latest in its Docker image.
Locking content to use a specific tag of a Docker image ensures stability. The tag is usually updated in newer versions of the content item. For more information, see Using Docker.
Yes
DO101
Validates the given content item uses a Demisto Docker image.
The Docker image used in a content item should originate from Demisto's Docker repository. This ensures that the Docker image is trusted, maintained, and compatible with the Demisto platform.
DO102
Validates the given content item uses a Docker image that is not the native image.
The native-image Docker image is intended for internal development and should not be used to run integrations or scripts.
DO103
Validates the given content item's Docker image exists in Docker Hub.
Platform-supported content must have images available in Docker Hub so they can be widely pulled and used.
DO104
Validates the given content item has a Docker image.
Python and PowerShell content runs in containers.
DO105
Validates the given content item uses a Docker image that is not deprecated.
Best practice is to use images that are maintained by the platform.
DO106
Validates the given content item's Docker image isn't outdated.
Updated Docker images ensure that the code doesn't use outdated dependencies, including bug fixes and fixed vulnerabilities.
Yes
DS:Description
DS100
Checks whether a description file exists for a beta integration.
A disclaimer for beta integrations is required.
DS101
Checks if a beta disclaimer exists in the detailed description.
A disclaimer for beta integrations is required.
DS104
Verifies that a description file is present for an integration.
We recommend a description file for each integration, which for example has additional details on how to configure the instance.
DS105
Checks if the DESCRIPTION file contains contribution details.
Ensures the contribution/partner details that are generated automatically are not duplicated.
DS106
Checks if the description file exists and the name is valid.
Ensures all integrations have all required documentation and the file name is according to our standards.
DS107
Validates that none of the description lines contains the word demisto.
Ensures the current name of the product is used rather than the old one.
DS108
Ensures all YAML file description fields end with a period.
Ensures documentation standards.
Yes
GF: Generic field
GF100
Checks if group field is set to 4.
Required by the platform.
Yes
GF101
Checks if the ID starts with generic_.
Required by the platform.
GF102
Checks if the unsearchable key is set to true.
Marking many items searchable causes index and search loads on the platform. Official demisto/content GenericField files must be set to unsearchable. In custom content, we recommend keeping the number of searchable fields to a minimum.
Graph
GR100
Detects content items that attempt to use other content items that are not supported in all of the marketplaces of the content item.
Ensures content graph proper construction.
GR101
Validates the source's fromversion >= the target's fromversion.
Prevents issues where used objects are not available due to a version mismatch.
GR102
Validates content items are not used in other content items which have a lower toversion.
Prevents issues where used objects are not available due to a version mismatch.
GR103
Validates there is no usage of unknown content items.
Content items should only use existing content items.
GR104
Validates there are no duplicate display names of packs in the repository.
Prevents confusion between packs.
GR105
Ensures each content item has a unique ID to prevent conflicts.
Duplicate IDs can cause conflicts and confusion.
GR106
Checks that every test playbook is linked to at least one content item. The content item has a tests key with the ID of the test playbook.
In the demisto/content repo, unlinked test playbooks are not run in CI (for PRs) unless the test playbook itself is modified. Proper linkage of test playbooks ensures content quality.
GR107
Validates that deprecated content items are not used in other content items.
Using deprecated content items can lead to unexpected behavior and should be avoided.
GR108
Validates that non-hidden packs do not have a hidden packs as mandatory dependencies.
Hidden packs are not available to install in the marketplace.
IF: Incident field
IF100
Checks if the name and cliName do not contain potential incident synonyms.
The name and cliName fields are limited by the platform.
IF101
Checks if the incident field is marked as content.
Required by the platform.
Yes
IF102
Checks if system flag is false.
Required by the platform.
Yes
IF103
Checks if a given field type is valid.
The types of the IncidentField are limited by the platform.
IF104
Checks if group field is set to 0.
Required by the platform.
Yes
IF105
Checks if cliName field is alphanumeric and lowercase.
Required by the platform.
IF106
Checks if cliName field is not a reserved word.
The cliName values of the incident field are limited by the platform.
IF111
Checks if the field type changed.
Changing the IncidentField type is not allowed by the platform.
IF113
Checks if the field name starts with its pack name or one of the item prefixes from pack metadata.
Required by the platform.
IF115
Checks if the unsearchable key is set to true.
Marking many items searchable causes index and search loads on the platform. Official demisto/content IncidentField files must be set to unsearchable. In custom content, we recommend keeping the number of searchable fields to a minimum.
IF116
Checks if incidentFields with multiSelect types have empty selectValues options.
Due to UI issues, empty values for the selectValues field are not supported.
Yes
IF119
Checks if incidentFields with singleSelect types have empty or more than one selectValues options.
Due to UI issues, more than one or only empty values for the selectValues field are not supported.
Yes
IM: Author image
The following are the integration logo requirements:
10 KB maximum size
Black and white or contrasting colors (no light colors)
Dimensions of 120x50 pixels
Transparent background
Only PNG format
No reversed logos or borders
IM100
Checks if the integration has an image path.
Images make it easier to find integrations.
IM101
Checks that the image file size matches the requirements.
The image needs to fit properly in the UI with maximum size 10 KB.
IM106
Checks if the integration has an image other than the default ones.
If an image is provided, it must not be a default image.
IM108
Checks that the author image file is not empty.
If an author image is provided, it must be valid.
IM109
Checks if the pack has an author image path.
Author images make it easier to identify the author.
IM111
Checks that the image file dimensions match the requirements.
The image needs to fit in the UI. The logo dimensions should be 120x50 pixels.
IN: Integration
IN100
Validates the proxy and insecure parameters are configured correctly.
The proxy and insecure parameters in an integration are built-in platform parameters.
Yes
IN101
Checks that outputs of reputation commands are uniform and adhere to standards.
Uniform outputs allow creating generic content. Read about generic reputation commands.
IN102
Validates the checkbox parameter is configured correctly with the required argument set to false.
A checkbox parameter that is required will fail (counts as missing) when unchecked, thus forcing users to always check it, turning it into a constant true value, rather than a dynamic checkbox.
Yes
IN104
Validates that the integration category is valid.
See the list of allowed categories in the platform.
IN106
Validates the command is valid as a reputation command.
Reputation commands must follow standards for consistency and compatibility.
IN107
Validates the reputation commands include the list of required contextPaths.
Reputation commands must include required contextPaths for consistency and reliable use in playbooks or scripts. For more information, see Mandatory Context Standards.
IN108
Checks whether the subtype is valid.
This field describes the major Python version, python2 or python3.
IN109
Validates that the id field doesn't include the substring beta.
The id field in an integration should not contain the word beta. This ensures unambiguous identification of production-ready integrations.
Yes
IN110
Validates the name field doesn't include the substring beta.
The name field in an integration should not contain the substring beta. This ensures unambiguous identification of production-ready integrations.
Yes
IN112
Validates that the display name of a beta integration contains the substring beta.
Beta integrations should have beta in the display name for clear identification and to manage user expectations.
IN113
Checks that there are no duplicate arguments for integrations.
Duplicate arguments cause confusion and unpredictable behavior.
IN114
Checks that there are no duplicate parameters for integrations.
Duplicate parameters cause confusion and unpredictable behavior.
IN115
Validates the contextPath field of each output is in the correct format.
The contextPath in an integration's output must follow the correct format to ensure data can be used in subsequent playbook steps. Incorrect contextPath formats can lead to errors or unexpected behavior. Read about context and outputs.
IN117
Validates type 17 configuration parameters do not include the display field.
The display name is handled by the platform.
Yes
IN118
Validates the integration parameter has a display field if it's not type 17.
Integration parameters should have a display field for clear user understanding, except for type 17 parameters.
IN121
Validates the fetch integration has the required parameters in the correct format.
Malformed or missing parameters can lead to errors or incomplete data. Read about fetching integrations.
IN122
Checks that all feed parameters are in the correct format.
Malformed or missing parameters can lead to errors or incomplete data. Read about feed integrations.
IN123
Checks whether the integration display name is versioned correctly.
Integration display names should end with v<number> for version clarity and consistency.
Yes
IN124
Checks that a parameter is not hidden if it should not be hidden.
Hiding these parameters can lead to confusion and may prevent the integration from working as expected. Only the following parameters may be hidden: longRunning, feedIncremental, and feedReputation.
Yes
IN125
Validates the max_fetch parameter has a default value.
To maintain optimal load in the platform, the maximum number of incidents per fetch is limited.
Yes
IN126
Checks that a fetch integration is not missing the first_fetch and max_fetch parameters.
The first_fetch and max_fetch parameters in fetch integrations ensure correct incident retrieval. Their absence or incorrect format can lead to errors or inconsistencies. For more information, see https://xsoar.pan.dev/docs/integrations/fetching-incidents#first-run.
IN127
Checks that a deprecated integration display name ends with (Deprecated).
Deprecated integration display names should end with (Deprecated) to clearly indicate their status. This prevents inadvertent use of unsupported integrations. Read about deprecation.
Yes
IN130
Checks that the integration is runnable.
Integrations must have a functional purpose, such as executing commands, fetching incidents, fetching indicators from a feed, or running a long-running process.
IN131
Checks that the integration is valid as a mappable integration.
For easy debugging and troubleshooting, integrations supporting schema mapping ismappable: true should include the get-mapping-fields command. This validator ensures the command is present in the integration YAML, enhancing maintainability and user experience.
IN134
Checks whether a content item has multiple default arguments.
Multiple default arguments are not supported by the platform and could lead to unexpected behavior.
IN135
Checks that the parameter display name starts with a capital letter and doesn't contain an underscore _.
For consistency and readability, parameter display names should start with a capital letter and not contain underscores.
Yes
IN139
Checks that the word incident isn't used in any of the command names or argument names for core pack integrations.
Helps maintain the flexibility of the platform.
IN141
Checks that an endpoint command has at least one of the required fields.
Without at least one of the required fields, the command may not function properly or may return incomplete or incorrect data. Read about generic endpoint commands.
IN142
Checks that the integration contains the correct additionalinfo fields for the list of parameters with predefined additionalinfo.
Ensuring the additionalinfo fields are correctly set in an integration's parameters promotes consistency and enhances user understanding of each parameter's purpose and usage.
Yes
IN144
Checks that a reputation command has isArray field set to true for its default argument.
Reputation commands often have multiple inputs to enrich. Without isArray=true, providing an array of inputs may impact performance. Read about reputation commands.
IN145
Checks that Cortex XSOAR-supported integrations do not have non-hidden type 4 parameters.
Parameters that contain API tokens or credentials should be of type Credentials (type 9) instead of Encrypted (type 4) to allow fetching credentials from an external vault. This ensures secure and efficient handling of sensitive data. Using the Encrypted type could prevent the integration from fetching the credentials from an external vault, which could lead to operational issues. Read about credentials.
IN146
Checks that there is no fromlicense parameter field in non-Cortex XSOAR-supported integrations.
The fromlicense parameter is intended for XSOAR-supported integrations, as they rely on values coming in the platform.
Yes
IN149
Checks that a contextPath has a description if it belongs to a predefined list of contextPaths that require a description.
Common outputs in integrations need descriptions for clarity and effective usage.
Yes
IN150
Checks that a SIEM integration display name ends with Event Collector.
Consistent naming convention ensures that users can easily understand what the integration is used for. Read more about naming conventions for event collection integrations.
Yes
IN151
Checks that all commands have at least one argument.
Prevents potential errors during execution due to missing arguments.
Yes
IN152
Checks that the default value of a checkbox parameter is valid.
Checkbox parameters' default values should be lowercase boolean strings (true, false) for correct interpretation and functionality.
Yes
IN153
Checks that the default URL parameter starts with https rather than http.
URL parameters should default to https for secure communication, as http could expose sensitive data.
Yes
IN154
Checks that feed integrations and integrations with reputation commands have a reliability parameter.
The reliability parameter is required to set an indicator's reliability.
IN156
Checks that the hidden field value contains only valid values.
Incorrect values can cause unexpected behavior or compatibility issues.
IN158
Checks that the description for non-deprecated integrations is not in the deprecation format.
Avoids confusion and ensures that users are correctly informed about the integration's status. Read more about deprecation.
IN159
Checks that the capitalization of reputation-command-specific keys is correct.
Ensures consistency and effective data passage between playbook tasks. Read about the standard context output for reputation commands.
IN160
Checks that the display name for non-deprecated integrations doesn't end with (Deprecated).
Avoids confusion and ensures that users are correctly informed about the integration's status. Read more about deprecation.
IN161
Checks that the marketplacev2 tag appears in the marketplaces list of a SIEM integration.
SIEM integrations must have the marketplacev2 tag for visibility in the Cortex XSIAM marketplace, enhancing usability. See required keys for event collection integrations.
Yes
IN162
Checks that the supportlevelheader for a collector integration in a partner pack is set to XSOAR.
Collector integrations in partner packs should specify the XSOAR support level to inform users about the support level provided by Cortex XSOAR. Read about the support level header.
Yes
IN163
Checks that the feedExpirationPolicy parameter is in the correct format for both incremental and fully fetched feeds.
A malformed expiration policy can lead to errors or incomplete data.
Yes
IT: Incident type
IT100
Checks that the included fields have a positive integer value.
Fields that have to be included cannot be type integer.
IT101
Checks that the playbook id is valid.
The playbook id has to be in a non-UUID format.
IT102
Checks that the extractSettings field is valid.
The extractSettings field needs to be in the correct format.
IT103
Checks that the autoExtractMode is valid.
The autoExtractMode possible options are:
All: To extract all indicator types regardless of auto-extract settings.
Specific: To extract only the specific indicator types set in the auto-extract settings.
LO: Layout
LO107
Checks that only supported types are used in the layout for Cortex XSIAM compatibility.
Limited by the platform.
MR: Modeling rule
MR100
Checks that each modeling rule has a corresponding schema file.
Each modeling rule must have a schema file.
MR101
Checks that the modeling rule keys rules and schema exist and are empty.
This validation is for compatibility reasons. Without the rules and schema keys, the modeling rules won't work.
MR106
Checks that each data type in the modeling rule schema files conforms to a predefined set of acceptable types.
Validating types in schema files is crucial for maintaining data integrity and compatibility across systems, preventing errors and ensuring reliable data processing.
MR107
Checks that the modeling rule dataset name in the XIF file matches the name in the schema files.
Ensures the dataset name matches between the schema and the XIF file to avoid discrepancies between the expected information and the information shown in the UI.
MR108
Checks that id and name in the modeling rule end with the correct suffixes.
To prevent confusion caused by ambiguous naming of modeling and parsing rules in the Cortex XSIAM UI, the validation ensures the rule id ends with ModelingRule and the rule name ends with Modeling Rule. This helps avoid naming conflicts and improves clarity in release notes.
PA: Pack
PA100
Validates all the tags in the tags field have a valid prefix.
This standardization allows for efficient filtering and grouping in the marketplace. See the list of valid prefixes.
Yes
PA101
Validates the version mentioned in the pack metadata matches the latest release notes version.
Clear documentation for each version change helps users know what's new. Read more about content pack versioning.
PA102
Validates the pack is deprecated when deprecation is required.
Ensures clarity for users and prevents potential confusion about deprecated content.
Yes
PA104
Validates the modules field includes only labels from the list of allowed labels.
There is currently one allowed module: compliance.
Yes
PA105
Validates the pack has the marketplacev2 label if it includes modules.
This field is only used in Cortex XSIAM.
Yes
PA107
Checks that mandatory fields exist in the pack_metadata.json file.
Missing fields may lead to unexpected behavior when content packs are uploaded.
Yes
PA108
Validates the pack name field exists and is different from the default name.
A unique and meaningful pack name is crucial for identifying the pack and its contents.
PA109
Validates the metadata description field isn't empty and is different from the default value.
A meaningful description helps users understand what the pack does.
PA111
Validates that the required metadata fields are not empty.
The following metadata fields are required: keywords, tags, categories, and useCases. These fields support pack identification and searchability.
PA113
Validates a partner or developer pack has an email or a url field completed.
Packs with partner or developer support levels require a contact method (email or URL) for user support and information.
PA114
Checks that the pack_metadata currentVersion is incremented when relevant changes are made.
When a pack is updated, its version must be updated to maintain traceability.
PA115
Validates the pack_metadata created field is in ISO 8601 format.
Required by the platform.
Yes
PA118
Validates the metadata's certification field is valid.
See list of allowed certifications in the platform.
PA119
Validates the metadata's useCases field contains only valid values.
See the list of allowed useCases in the platform.
Yes
PA120
Validates the metadata's tags field includes only approved tags.
Using approved tags makes it easier for users to find the packs that suit their needs.
Yes
PA121
Validates no changes were made to the pack's price field.
Changing this field affects paying customers. In the demisto/content repository, this requires a force-merge.
Yes
PA123
Validates the pack has at least one of the following: playbook, incident type, or layout if the tags field contains the Use Case tag.
Correct categorization helps users find packs that suit their needs.
Yes
PA124
Validates core packs do not depend on non-core packs.
Core packs should be self-contained.
PA125
Validates that the pack name follows the naming conventions.
Pack names should follow conventions for consistency and readability in the marketplace.
PA127
Validates the pack_metadata contains a valid url field.
URLs help users access support or report issues for the pack directly. For more information, see the fields in the pack_metadata.json file.
Yes
PA128
Checks for required pack files.
These files are standard in the demisto/content repository.
Yes
PA130
Validates the pack_metadata currentVersion field is in a valid format.
Content versions use semantic versioning to indicate the significance of the changes between two versions.
PA131
Validates the pack_metadata contains a defaultDataSource if there is more than one data source.
Wizards and other tools require the default data source to be set.
Yes
PA132
Checks that the pack_metadata contains a valid defaultDataSource when provided.
Wizards and other tools require the default data source to be set.
Yes
PB: Playbook
PB100
Checks whether the playbook has a role name. If the Playbook has a role name it is not valid.
Playbooks out-of-the-box should not have a role set since this is customizable by the customer.
PB101
Checks whether an ask conditional has a task with an unreachable next task condition.
If the condition cannot be reached the playbook cannot proceed to the next task.
PB103
Checks whether there is an unconnected task.
Ensure there are no unconnected tasks so the playbook will work as expected.
PB104
Checks whether a deprecated playbook has a valid description.
Ensures deprecated content descriptions are consistent.
PB105
Checks whether the playbook has a DeleteContext script with all arguments set to Yes.
Playbooks with a DeleteContext script with all arguments set to Yes are not valid.
PB106
Checks whether the playbook uses an instance.
If a playbook uses a specific instance it can leads to errors because not all the users have the same instance.
Yes
PB108
Checks that the task ID and the id under the task field are in UUID format.
Each task should have a unique ID in UUID format to avoid unknown behavior and breaking the playbook.
PB109
Checks that the taskid field and the id field under the task field contain equal values.
System requirements
PB114
Validates that playbooks for indicator types are on quiet mode.
Playbooks for indicators typically execute on thousands of indicators so they need to be on quiet mode.
Yes
PB115
Checks whether the quietmode field of all tasks in a playbook are not set to the default value.
Confirms whether quiet mode is turned off.
Yes
PB116
Checks that all playbook tasks stop when encountering an error.
For indicator playbooks, tasks typically execute on thousands of indicators. If a playbook task does not stop on errors, instances can crash and tasks relying on its output will fail.
PB118
Checks that all inputs described in the playbooks input section are used in tasks.
Depending on the task type that you select, and the script that you are running, your playbook task has inputs and outputs.
Inputs are data pieces that are present in the playbook or task. The inputs are often manipulated or enriched and they produce outputs. Outputs are objects whose entries will serve the tasks throughout the playbook, and they can be derived from the result of a task or command.
For more information, see Playbook inputs and outputs.
For more information, see Playbook inputs and outputs.
PB119
Checks that all inputs used are defined.
Inputs that are used but not provided to a playbook is probably an oversight.
PB122
Checks whether branches of built-in conditional tasks are handled properly.
Ensures the playbook logic is correct.
PB123
Checks whether an ask conditional has unhandled reply options.
Ensures the reply options are handled.
PB124
Checks that all conditional tasks contain at least two next tasks.
Ensure unhandled cases are note missed in a playbook.
PB125
Checks that a conditional task does not have only a default next task.
Ensures a conditional task has next tasks more than just the default next task so it implements different conditions.
PB126
Checks that conditional tasks have an execution path besides for the default.
Ensures that conditional tasks have more execution paths than just the default path so they implement different conditions.
PB127
Checks that any YAML keys that are Marketplace only have a default non-Marketplace counterpart.
To validate the existence of required YAML keys, we need to make sure that in addition to a specific Marketplace key (for example mykey:xsoar) there is also a basic key with no specific Marketplace (for example: mykey).
Yes
PR: Parsing rule
PR101
Checks that the id and name in the parsing rule end with the correct suffixes.
To prevent confusion caused by ambiguous naming of modeling and parsing rules in the Cortex XSIAM UI, this validation ensures that the rule id ends with ParsingRule and the name ends with Parsing Rule. This helps avoid naming conflicts and improves clarity in release notes.
RM: Readme
RM100
Checks that no default section contains only a heading.
Ensures that there are no default leftovers such as:
Non-specific version numbers.
Default description belonging to one of the example integrations.
RM101
Checks that image paths are not absolute, and suggests a valid path when an absolute path is found.
In official Marketplace content, ensures that the images can be used properly in the upload flow.
RM102
Validates that all context outputs defined in the README file are present in the YAML file, and vice versa.
Ensures consistency between the README and YAML files to maintain accurate documentation and prevent discrepancies.
RM104
Validates that the pack contains a full README file with pack information.
Meaningful, complete documentation makes it easier for users to use the content.
RM105
Checks that the README file differs from the pack description.
An informative README helps users learn about the product and its use cases.
RM106
Validates none of the README file lines contain the word demisto.
Ensures that the current name of the product is used rather than the old one.
RM107
Checks that the generic placeholder does not appear in the README file.
Ensures that the placeholder text is replaced before the content is published.
RM108
Verifies that images references in the README and description files are relative and that the images are stored in the doc_files folder.
Using relative references to files in the repository folder enhances security by reducing reliance on external links, minimizing the risk of link manipulation or redirection attacks.
RM109
Validates that a README file exists for the content item.
Ensures that the content item is documented with use cases, inputs, and outputs.
RM110
Validates that all commands are documented in the README file.
Ensures that all commands are documented in the README file to help users understand the available functionality.
RM113
Checks that none of the README lines contain the disallowed copyright section keywords.
Marketplace content is licensed under the MIT license, so pack-specific copyright notices are not permitted.
RM114
Validates that images in the README file exist in the doc_files folder.
Images that are missing from the doc_files folder do not render in the published Markdown.
RM115
Checks that no default auto-generated sections remain empty.
Ensures that there are no default leftovers such as:
Non-specific version numbers.
Default description belonging to one of the example integrations.
RM116
Validates that the README file is not too short.
Ensures that the README file contains sufficient information.
RN: Release notes
RN103
Validates that the pack contains a complete release notes file.
Meaningful, complete release notes make it easier for users to understand what changed.
RN105
Checks that there is no more than one added release notes file for each pack version.
More than one release notes file for a version may cause confusion and missing information.
RN108
Validates that a new pack does not have release notes.
New packs do not require release notes because they do not have any updates.
RN112
Checks that breaking-change release notes exist for packs with breaking changes, and that they are documented correctly.
Breaking changes must be well documented so that users can see them when updating to a new version.
RN114
Validates that content types are documented as #### headings and content items as ##### headings in the release notes.
Ensures that the documentation is accurate and clear.
RN116
Validates that the release notes have either a valid first-level heading or a valid force heading.
Enforces a proper release notes structure to ensure that the documentation is readable.
RP: Reputation (indicator type)
RP101
Validates that the expiration field has a non-negative integer value.
Aligns with the platform requirements. A negative expiration value is not supported by the platform.
RP102
Validates that the id and details fields are equal.
The platform requires the id and details values to match.
RP103
Validates that the indicator type id field has a valid value.
Ensures that the indicator type id matches a defined indicator type.
SC: Script
SC100
Checks that the script name is versioned correctly and ends with V<number>.
Ensures consistency across content items.
Yes
SC105
Checks that the script arguments in core packs do not contain the word incident.
In Cortex, the word incident can be replaced by another keyword. To ensure compatibility with this feature, command names, command arguments, and script arguments in core packs and scripts must not use the word incident. This maintains the flexibility of the system and prevents potential issues caused by keyword replacement.
SC106
Checks that the script runas field is not set to DBotRole.
For security reasons, the runas field should not be set to DBotRole.
SC109
Validates that there are no scripts with the same type and name.
Duplicate names cause confusion and unpredictable behavior.
Last updated
Was this helpful?