Subject: Vulnerability report - [PRODUCT] - [ONE-LINE SUMMARY]
To: [email-masked]

Thank you for reporting this to us.

Fill in whatever you can and send. Every field is optional -- a partial report
is far better than none. Delete anything that does not apply.

Our full disclosure policy, including our safe harbour commitment for
good-faith research, is at https://incosasolutions.com/security/

IMPORTANT: if you believe this vulnerability is being actively exploited right
now, please add "ACTIVELY EXPLOITED" to the subject line above. It changes how
quickly we have to act and what we are legally required to do.

================================================================
1. WHICH PRODUCT
================================================================

Product line ..... (i-C4C / i-C4C GO / inVision / programming tools /
                    cloud service or API / website / other)
Model or part no.
Hardware revision  (if known)
Firmware/software version
Configuration ....  (project or file name, if relevant)
Serial number ....  (optional - helps us identify the production batch)
If a website ..... (URL and specific page or endpoint)

Where did you test this?
  [ ] On a device I own
  [ ] On a device I have written permission to test
  [ ] On a test bench or lab setup
  [ ] On an Incosa website
  [ ] Other:

  NOTE: please do not test on live installations or machinery in operation.
  Our products control overhead cranes and industrial equipment. A test that
  seems harmless on a bench can injure or kill someone in the field.

================================================================
2. WHAT IS THE PROBLEM
================================================================

Summary (one or two sentences):

Full description:

Vulnerability class (optional - CWE, or plain description):

================================================================
3. HOW TO REPRODUCE IT
================================================================

Step by step. Include exact commands, inputs, payloads and settings.

  1.
  2.
  3.
  4.

Setup or preconditions needed:

Tools used (and versions):

How reliably does it reproduce?
  [ ] Every time
  [ ] Usually
  [ ] Intermittently (roughly ___ % of attempts)
  [ ] Reproduced once, not retried

================================================================
4. WHAT AN ATTACKER COULD ACHIEVE
================================================================

Impact - what does a successful attack get someone?

SAFETY CONSEQUENCE
Could this affect the safe operation of machinery - motion control, load
handling, emergency stop, interlocks, operator safety? Tell us even if you
are unsure. We would far rather over-assess this than miss it.

  [ ] No safety consequence that I can see
  [ ] Possibly - explained below
  [ ] Yes - explained below

COULD THIS AFFECT INSTALLATIONS OTHER THAN THE ONE TESTED?
For example shared or hard-coded credentials, reusable keys, a flaw in
firmware verification, or something that lets an attacker move from one
device to another.

================================================================
5. WHAT ACCESS DOES AN ATTACKER NEED
================================================================

Position
  [ ] Remote, over the internet
  [ ] Same local network as the device
  [ ] Direct network connection to the device
  [ ] Physical access to the device (enclosure, ports, cabling)
  [ ] Physical disassembly of the device
  [ ] Access to the engineering or commissioning PC
  [ ] Access to programming tools or configuration files
  [ ] Access to update media (USB, service laptop)

Credentials
  [ ] None needed
  [ ] Default or published credentials
  [ ] Valid operator credentials
  [ ] Valid engineering or administrator credentials

Other
  [ ] Requires user or operator interaction:
  [ ] Requires a specific configuration:
  [ ] Requires physical presence during a specific operation:

Anything else about the realistic attack path:

================================================================
6. EVIDENCE
================================================================

Attached to this email:
  [ ] Proof-of-concept code or script
  [ ] Screenshots
  [ ] Log extracts
  [ ] Packet capture
  [ ] Video
  [ ] Configuration or project file
  [ ] Firmware image or extract
  [ ] Other:

Tell us if anything is too large to send and we will arrange a transfer.

We do not currently publish a PGP key. If you are not comfortable sending
something in plain email, say so and we will agree a secure channel with you.

================================================================
7. SEVERITY -- OPTIONAL, SKIP IT IF YOU LIKE
================================================================

SKIP THIS WHOLE SECTION IF YOU DO NOT USE CVSS. It is genuinely
optional. We score every report ourselves regardless, and a report
without a score is not worth less to us. If you would rather just say
"this seems serious" or "probably minor", write that on the last line
and move on.

CVSS is the Common Vulnerability Scoring System (first.org/cvss) --
a standard way of expressing severity as a reproducible number.

CVSS version ..... (4.0 / 3.1 / not assessed)
Vector string ....  e.g. CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/...
                    The vector matters more to us than the number,
                    because we can re-derive the number from it.
Base score .......  (0.0 - 10.0)

SAFETY IMPACT -- the part we care about most
If you are using CVSS v4.0, please set the Supplemental Safety metric.
Its values are defined against IEC 61508, the functional safety
standard our equipment is built to:

  S:P  Present    -- consequences are marginal, critical or catastrophic
  S:N  Negligible -- consequences are negligible

  Safety metric ... (S:P / S:N / not assessed)

We ask because CVSS systematically under-rates our kind of equipment.
A flaw needing physical access scores lower than the same flaw over a
network -- but our devices sit on overhead cranes, where physical
access is routine for a service engineer and the worst outcome is not
data loss. If you think something could affect motion, load handling,
emergency stop or interlocks, tell us in plain words even if you skip
every other line in this section.

YOUR OWN VIEW IN PLAIN WORDS
(critical / high / medium / low -- and why, in a sentence)

We do our own assessment and will tell you if we reach a different
conclusion. That is a normal conversation, not a disagreement.

================================================================
8. EXPLOITATION STATUS
================================================================

Do you have any evidence this is being exploited in the real world?
  [ ] No - I found this through my own testing or research
  [ ] I am not sure
  [ ] YES - I have seen evidence of real-world exploitation

If yes or unsure, describe what you saw. Even a partial or uncertain
indication is worth telling us.

  If you ticked YES, please also add "ACTIVELY EXPLOITED" to the subject line.

================================================================
9. DISCLOSURE
================================================================

Do you intend to publish?
  [ ] No
  [ ] Yes - planned date:
  [ ] Yes, but the timing is flexible
  [ ] Undecided

Have you reported this to anyone else? (a CERT/CSIRT, a coordinating body,
another vendor, a bug bounty platform, an upstream open-source project)
  [ ] No
  [ ] Yes - to whom, when, and any reference number:

Is there a deadline you are working to? Some coordinating bodies impose one.
Tell us early rather than late - we would rather plan around it than
discover it.

================================================================
10. HOW SHOULD WE CREDIT YOU
================================================================

We credit reporters by name in the advisory, in the release notes for the
version containing the fix, and in the acknowledgments section of our
disclosure policy - unless you tell us not to.

  [ ] By my name:
  [ ] By this handle:
  [ ] By my organisation:
  [ ] Anonymously - please do not name me

Your name .......
Your email ......
Organisation ....  (if reporting on behalf of one)
Preferred language  (English / Dutch / other)

Would you like a call at any point? We do not require you to work through
email or any automated tool.
  [ ] No, email is fine
  [ ] Yes - best number and time:

================================================================
11. ANYTHING ELSE
================================================================

================================================================
WHAT HAPPENS NEXT
================================================================

  Within 3 business days ....... we acknowledge your report and give you a
                                 case reference
  Within 15 business days ...... we tell you whether we could reproduce it,
                                 whether we consider it a vulnerability, and
                                 our initial view of severity
  Every 30 days after that ..... a progress update while the case is open,
                                 even if the update is "no change yet"
  Within 90 days, or with the
  next release for the affected
  product, whichever is first .. we aim to have a fix or mitigation available
                                 and to publish, with credit to you

We will tell you BEFORE a deadline if we are going to miss it, not after.

Our safe harbour commitment applies to you if you have followed the rules of
engagement in our disclosure policy. See section 6 at
https://incosasolutions.com/security/

Thank you for taking the time to tell us.

--
Incosa Solutions
[email-masked]
https://incosasolutions.com/security/