1990282 - SwissSign: recommendation on linting software updates

Status: ASSIGNED

(CA Program :: CA Certificate Compliance, task)

Description

[Sandy Balzer]

Preliminary Incident Report

Summary

• Incident description: The audit report contains a recommendation regarding the improvement of SwissSign’s process for updating the linting software to ensure that updates are always completed within three months of a linter release.

• Relevant policies: CA/B-F TLS BR, 6.6.1

• Source of incident disclosure: Audit

Comment 1

[Sandy Balzer]

Full Incident Report

Summary

• CA Owner CCADB unique ID: A000049
• Incident description: The audit report contains a recommendation regarding the improvement of SwissSign’s process for updating the linting software to ensure that updates are always completed within three months of a linter release.
• Timeline summary:
  • Non-compliance start date: N/A (audit recommendation and not non-compliance)
  • Non-compliance identified date: N/A (audit recommendation and not non-compliance)
  • Non-compliance end date: N/A (audit recommendation and not non-compliance)
• Relevant policies: CA/B-F TLS BR, 6.6.1
• Source of incident disclosure: Audit

Impact

• Total number of certificates: N/A
• Total number of "remaining valid" certificates: N/A
• Affected certificate types: N/A
• Incident heuristic: N/A
• Was issuance stopped in response to this incident, and why or why not?: Certificate issuance was not halted, as certificate issuance was not impacted.
• Analysis: N/A
• Additional considerations: SwissSign uses a PKI system from an external vendor. This PKI system has various linters included and the vendor updates the linters with new releases of the PKI software. SwissSign did not explicitly monitor updates of the linters as CA/B TLS BR 6.6.1 is a SHOULD requirement.

Timeline

• 12.09.2025 Audit report containing this recommendation published

Related Incidents

none found

Root Cause Analysis

Contributing Factor #1:

• Description: Auditors recommend to monitor releases of the linters included in the CA software to ensure updates within 3 months of new versions become available.
• Timeline: N/A
• Detection: Audit
• Interaction with other factors: N/A
• Root Cause Analysis methodology used: N/A

Lessons Learned

• What went well: N/A
• What didn’t go well: N/A
• Where we got lucky: N/A
• Additional: N/A

Action Items

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Setup monitoring of linter versions to trigger vendor to include newer versions in the CA software	Prevent	Root Cause # 1	Monitoring in place	2026-04-30	In progress

Appendix

N/A

Comment 2

[chrome-root-program]

[In response to Comment 1]

Thank you for filing this incident report and those others identified during SwissSign’s most recent audit period.

While reviewing the TLS BR Audit Attestation, we note no nonconformities, but several “recommendations”. We’re not used to seeing recommendations in the Audit Attestation. For example, past SwissSign Audit Attestations only include minor nonconformities - 1, 2, and 3.

Q1: Can you help us understand the difference between a “recommendation” and a “minor nonconformity”? We only see minor nonconformity defined in ETSI EN 319 403-1 V2.3.1, but it’s possible that we’re missing something.

In the case of the recently filed reports, including this one, we lack essential context regarding the circumstances that resulted in the Qualified Auditor’s recommendations (i.e., we understand the auditor made a recommendation, but we don’t know what motivated that recommendation).

Additional questions specific to the linting recommendation:

Q2: Can you share which linters (and versions) were in use at the time of this recommendation, highlighting which were out of date and by how long (release of in-use version vs release of most current version)?

Q3: To support the 'Impact: N/A' assessment in your report, can you describe the analysis you performed? Specifically, did you retroactively run the updated linter versions against all certificates issued during the delay to confirm no non-compliant certificates were missed?

Q4: Comment 1 includes “SwissSign did not explicitly monitor updates of the linters as CA/B TLS BR 6.6.1 is a SHOULD requirement.” Can you help us understand SwissSign’s threshold for performing recommended, but not required practices?

Q5: Does the ~7.5 month Action Item timeline on this bug represent the time necessary to establish the ability to independently push updates to the in-use linters, separately from your CA software vendor releases?

Q6: Is SwissSign making any clear commitments as part of this action plan, for example not relying on a linter version that’s been superseded by ‘N’ weeks? Or, a commitment to run updated versions of linting packages out-of-band while waiting for updates to land in the CA software?

Comment 3

[Sandy Balzer]

(In reply to chrome-root-program from comment #2)

[In response to Comment 1]

Thank you for filing this incident report and those others identified during SwissSign’s most recent audit period.

While reviewing the TLS BR Audit Attestation, we note no nonconformities, but several “recommendations”. We’re not used to seeing recommendations in the Audit Attestation. For example, past SwissSign Audit Attestations only include minor nonconformities - 1, 2, and 3.

Q1: Can you help us understand the difference between a “recommendation” and a “minor nonconformity”? We only see minor nonconformity defined in ETSI EN 319 403-1 V2.3.1, but it’s possible that we’re missing something.

In the case of the recently filed reports, including this one, we lack essential context regarding the circumstances that resulted in the Qualified Auditor’s recommendations (i.e., we understand the auditor made a recommendation, but we don’t know what motivated that recommendation).

Additional questions specific to the linting recommendation:

Q2: Can you share which linters (and versions) were in use at the time of this recommendation, highlighting which were out of date and by how long (release of in-use version vs release of most current version)?

Q3: To support the 'Impact: N/A' assessment in your report, can you describe the analysis you performed? Specifically, did you retroactively run the updated linter versions against all certificates issued during the delay to confirm no non-compliant certificates were missed?

Q4: Comment 1 includes “SwissSign did not explicitly monitor updates of the linters as CA/B TLS BR 6.6.1 is a SHOULD requirement.” Can you help us understand SwissSign’s threshold for performing recommended, but not required practices?

Q5: Does the ~7.5 month Action Item timeline on this bug represent the time necessary to establish the ability to independently push updates to the in-use linters, separately from your CA software vendor releases?

Q6: Is SwissSign making any clear commitments as part of this action plan, for example not relying on a linter version that’s been superseded by ‘N’ weeks? Or, a commitment to run updated versions of linting packages out-of-band while waiting for updates to land in the CA software?

Thank you for your questions. Please find our answers below:

Q1a: Difference between “recommendation” and “minor nonconformity”
Response:
According to ETSI EN 319 403-1 V2.3.1, a minor nonconformity refers to a deviation that does not compromise the overall conformity of the system but should be corrected. In contrast, a recommendation is an auditor's suggestion for improvement that does not reflect a deviation from the standard. In this case, the recommendation was made to enhance SwissSign’s proactive monitoring of linter updates, even though the current process does not violate any requirements. Our reading of the Audit incident report guidelines [https://www.ccadb.org/cas/incident-report#what-is-considered-an-audit-finding] is that such that any recommendation or opinion of the auditors must be posted as Bugzilla.

Q1b: Motivation of the auditor for the recommendation
Response:
We are in contact with our Audit Body to formulate an answer and will post update once available.

Q2: Linters and versions in use at the time of recommendation
Response:
At the time of the on-site audit (June 2025), SwissSign was using the linter versions embedded in our CA software provided by our external PKI vendor:
• certlint: v1.7.7-0.10.0 (in use since end of 2022; latest public version is ~7 years old)
• x509lint: e2d7fe9b9a487e141330be3f677bd7c6737b31f9-0.10.0 (in use since end of 2022; latest public version is ~5 years old)
• zlint: v3.6.5-0.10.0 (current at time of on-site audit), latest available: v3.6.7 (released 2025-07-07)
• pkilint-smime: 0.12.11 (03467b936bd19148997c5b7fca10a8dffedfe723-0.10.0) (current at time of on-site audit), latest available: 0.12.13 (released 2025-09-05)
Note: Ongoing discussion regarding pseudonym abbreviation in CN (pkilint issue #155).
• SwS-Linter (internal): Version updated on 21.07.2025
The vendor of our PKI system updates linters with each major/minor release, typically every two months. Historically, this cadence ensured that linters were never significantly outdated. However, auditors recommended implementing independent monitoring to mitigate potential risks if release frequency decreases. SwissSign has adopted a process to check linter versions quarterly and escalate updates to our vendor when discrepancies are found.

Q3a: Justification for 'Impact: N/A'
Response:
SwissSign assessed the impact of delayed linter updates and concluded that certificate issuance was not affected. This assessment is based on our continuous use of the internally developed SwS-Linter, which is run against all valid certificates. While the CA/B Forum Self-Audit requirement specifies a quarterly review of 3% of issued certificates, SwissSign exceeds this by applying SwS-Linter to 100% of valid certificates. This proactive approach ensures that any compliance issues are detected early, supporting our conclusion that the delayed updates did not result in non-compliant certificate issuance.

Q3b: Retroactively run the updated linters
Response:
We did run the linters at SwissSign but not in latest updated versions, we are updating our internal process to more regularly update the linters. Additionally SwissSign uses its own linter, SwS-Linter, developed specifically for self-auditing. This tool is already run against all valid certificates, providing broader and more consistent coverage than the 3% sampling required by CA/B Forum guidelines. We are also planning to extend SwS-Linter to run daily, further strengthening our compliance monitoring.

Q4: Threshold for implementing “SHOULD” requirements
Response:
SwissSign evaluates “SHOULD” requirements based on risk, feasibility, and operational impact. While not mandatory, we treat such recommendations seriously, especially when they pertain to certificate compliance. In this case, the absence of explicit monitoring was not due to disregard but rather reliance on our vendor’s update process. Following the audit, we are implementing internal monitoring to ensure timely updates.

Q5: Timeline for Action Item
Response:
We set the same implementation timeline for all action items to the point when we will start internal preparation for the next audit cycle. We think that the main benefit of these audit Bugzillas for recommendations was for the community to be aware of possible improvements that other CAs could consider. Also, these recommendations have a lower implementation priority and therefore a due date further in the future has been set.

Q6: Commitments re linter versions
Response:
SwissSign is committed to improving its linter update process. As part of our action plan, we will:
- Monitor linter releases independently.
- Request vendor updates within a maximum of 3 months of public release.

We are happy to provide further clarifications if needed.

Comment 4

[Dimitris Zacharopoulos]

(In reply to Sandy Balzer from comment #3)
[...]

Thank you for your questions. Please find our answers below:

Q1a: Difference between “recommendation” and “minor nonconformity”
Response:
According to ETSI EN 319 403-1 V2.3.1, a minor nonconformity refers to a deviation that does not compromise the overall conformity of the system but should be corrected. In contrast, a recommendation is an auditor's suggestion for improvement that does not reflect a deviation from the standard. In this case, the recommendation was made to enhance SwissSign’s proactive monitoring of linter updates, even though the current process does not violate any requirements. Our reading of the Audit incident report guidelines [https://www.ccadb.org/cas/incident-report#what-is-considered-an-audit-finding] is that such that any recommendation or opinion of the auditors must be posted as Bugzilla.

Neither "recommendations" nor "opinions" are mentioned in the IRGs. It's fine if you decide to disclose more information for additional transparency but, in my understanding, this is not currently required.

Q1b: Motivation of the auditor for the recommendation
Response:
We are in contact with our Audit Body to formulate an answer and will post update once available.

I'm equally surprised with your auditor's decision to include "recommendations" in the audit attestation letter. In fact, TS 119 403-2 only requires the inclusion of non-conformities (no distinction between "minor" and "non-minor"). Similarly, the AAL templates from ACAB-c only states about listing "non-conformities". Nothing is mentioned about "recommendations".

[...]

Q3a: Justification for 'Impact: N/A'
Response:
SwissSign assessed the impact of delayed linter updates and concluded that certificate issuance was not affected. This assessment is based on our continuous use of the internally developed SwS-Linter, which is run against all valid certificates. While the CA/B Forum Self-Audit requirement specifies a quarterly review of 3% of issued certificates, SwissSign exceeds this by applying SwS-Linter to 100% of valid certificates. This proactive approach ensures that any compliance issues are detected early, supporting our conclusion that the delayed updates did not result in non-compliant certificate issuance.

This would only be applicable if SwS-Linter covered 100% of the checks performed by zlint and pkilint. The fact that you are using zlint and pkilint indicates that SwS-Linter probably does not cover 100% of the requirements. It would make sense to check all valid certificates against the latest versions of zlint and pkilint to make sure everything is covered.

Comment 5

[Sandy Balzer]

(In reply to Sandy Balzer from comment #3)

Q1b: Motivation of the auditor for the recommendation
Response:
We are in contact with our Audit Body to formulate an answer and will post update once available.

Please find the reply from our Auditors below.

Q1b: Motivation of the auditor for the recommendation
TÜV AUSTRIA GmbH Response:
According to our (the CABs) policies, called conformity assessment scheme, a recommendation is a finding of the following kind: it allows the CAB (auditors and certifier) to take a positive certification decision but the TSP shall remediate the finding until the next regular onsite audit. In this case, it means, it allows us to take positive decision and issue the AAL.

In case of this particular recommendation, the auditors decided to define it for the following reasons: Baseline Requirements V2.0.6 (Ballot SC-75, approved after the annual audit of SwissSign) introduced a new requirement in chapter 6.6.1 that a CA should monitor for updates when using external public linters and update the used linter within 3 months.

As the CA software, which SwissSign uses, is implemented by an external provider, SwissSign relied on the external provider for the updates of the implemented public linters. Based on this observation, the auditors recommended that SwissSign implements also internal monitoring for new versions of the external public liners in order to better control and enforce the external providers updates.

Comment 6

[Sandy Balzer]

(In reply to Dimitris Zacharopoulos from comment #4)

(In reply to Sandy Balzer from comment #3)
[...]

Thank you for your questions. Please find our answers below:

Q1a: Difference between “recommendation” and “minor nonconformity”
Response:
According to ETSI EN 319 403-1 V2.3.1, a minor nonconformity refers to a deviation that does not compromise the overall conformity of the system but should be corrected. In contrast, a recommendation is an auditor's suggestion for improvement that does not reflect a deviation from the standard. In this case, the recommendation was made to enhance SwissSign’s proactive monitoring of linter updates, even though the current process does not violate any requirements. Our reading of the Audit incident report guidelines [https://www.ccadb.org/cas/incident-report#what-is-considered-an-audit-finding] is that such that any recommendation or opinion of the auditors must be posted as Bugzilla.

Neither "recommendations" nor "opinions" are mentioned in the IRGs. It's fine if you decide to disclose more information for additional transparency but, in my understanding, this is not currently required.

Q1b: Motivation of the auditor for the recommendation
Response:
We are in contact with our Audit Body to formulate an answer and will post update once available.

I'm equally surprised with your auditor's decision to include "recommendations" in the audit attestation letter. In fact, TS 119 403-2 only requires the inclusion of non-conformities (no distinction between "minor" and "non-minor"). Similarly, the AAL templates from ACAB-c only states about listing "non-conformities". Nothing is mentioned about "recommendations".

[...]

Q3a: Justification for 'Impact: N/A'
Response:
SwissSign assessed the impact of delayed linter updates and concluded that certificate issuance was not affected. This assessment is based on our continuous use of the internally developed SwS-Linter, which is run against all valid certificates. While the CA/B Forum Self-Audit requirement specifies a quarterly review of 3% of issued certificates, SwissSign exceeds this by applying SwS-Linter to 100% of valid certificates. This proactive approach ensures that any compliance issues are detected early, supporting our conclusion that the delayed updates did not result in non-compliant certificate issuance.

This would only be applicable if SwS-Linter covered 100% of the checks performed by zlint and pkilint. The fact that you are using zlint and pkilint indicates that SwS-Linter probably does not cover 100% of the requirements. It would make sense to check all valid certificates against the latest versions of zlint and pkilint to make sure everything is covered.

Thank you for your input. We are currently clarifying if recommendations should lead to audit finding Bugzillas or not. We will post results here, as soon as we have them.

Also, we are evaluating your input regarding re-linting.

Updated Action Items

Action Items

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Setup monitoring of linter versions to trigger vendor to include newer versions in the CA software	Prevent	Root Cause #1	Monitoring in place	2026-04-30	In progress
Clarify audit recommendations applicability for CCADB audit finding reporting	Prevent	n/a	Clarification published	2025-11-15	In progress
Evaluate re-linting of all certificates after linter update	Prevent	Root Cause #1	Documented decision	2025-11-15	In progress

Comment 7

[Sandy Balzer]

We're clarifying the question raised by Dimitris in comment 5 and monitoring this Bugzilla for Community feedback.

Comment 8

[chrome-root-program]

Thank you for sharing your auditor’s motivation in comment 5. We’re still a bit confused by the statement: “According to our (the CABs) policies, called conformity assessment scheme, a recommendation is a finding of the following kind: it allows the CAB (auditors and certifier) to take a positive certification decision but the TSP shall remediate the finding until the next regular onsite audit. In this case, it means, it allows us to take positive decision and issue the AAL.” because:

1. “recommendation” is not defined in ETSI EN 319 403-1 V2.3.1 and further, as highlighted in comment 4 it is not included in ETSI TS 119 403-2 V1.2.4 or the ACAB’c AAL templates.
2. we were under the impression that “positive certification decision(s)” were taken today and AALs issued, despite TSPs still needing to remediate the “finding(s)” before another audit.

In short, we thought minor non-conformities were intended to accomplish positive decisions and AAL issuance, today, because that’s what we routinely see.

(Q1): Maybe SwissSign or its CAB can add a bit more context and clarity on what a “recommendation” is and how we might be able to reliably interpret one under the ETSI scheme?

Tangentially, in reviewing comment 4: “I'm equally surprised with your auditor's decision to include "recommendations" in the audit attestation letter. In fact, TS 119 403-2 only requires the inclusion of non-conformities (no distinction between "minor" and "non-minor").” and ETSI TS 119 403-2 V1.2.4, itself, we do find it curious that the change log describes “October 2020 CR#3 "Delete statement about findings of critical non-conformities": see PTA-4.3-08” because today, we only see minor non-conformities in the AALs disclosed to Root Store Operators, and this TS seems to suggest that the concept of critical non-conformities could have been present in the past.

From comment 3: “Our reading of the Audit incident report guidelines [https://www.ccadb.org/cas/incident-report#what-is-considered-an-audit-finding] is that such that any recommendation or opinion of the auditors must be posted as Bugzilla.”. The CCADB IRGs state:

Qualifications, non-conformities, and other deviations or omissions identified during audits are considered “findings.”
These items are commonly, but not exclusively, presented as either:

- major non-conformities,
- minor non-conformities,
- qualifications,
- qualified opinions, or
- other matters.

“(Qualified) opinions” are indeed listed in the description, but this was in reference to the WebTrust scheme, as we’re not aware of the term being used in the ETSI scheme. The concept of recommendations under the ETSI scheme is new to us and was not previously considered in the audit finding description.

Comment 5 states: “In case of this particular recommendation, the auditors decided to define it for the following reasons: Baseline Requirements V2.0.6 (Ballot SC-75, approved after the annual audit of SwissSign) introduced a new requirement in chapter 6.6.1 that a CA should monitor for updates when using external public linters and update the used linter within 3 months.”

We understand that the audit period covered SwissSign’s policies and practices between June 15, 2024 and June 13, 2025. Further, the related TLS BR updates added in SC-075 were adopted June 28, 2024 and effective August 6, 2024. Among other changes, Section 4.3.1.2 of v2.0.6 of the TLS BRs states: “Effective 2025-03-15, the CA SHALL implement such a Linting process.” and Section 6.6.1 states: “If a CA uses Linting software developed by third parties, it SHOULD monitor for updated versions of that software and plan for updates no later than three (3) months from the release of the update.” It seems to us that SC-75 was approved before the end of the SwissSign audit and the monitoring of linter updates within 3 months as a SHOULD statement was within the audit period itself.

(Q2): Again, not fully understanding the intention of a “recommendation” in the AAL, is it intended to account for not adhering to SHOULD statements from the TLS BRs?

Comment 9

[Roman Fischer]

Dear community,

A clarification meeting between the root store operators, our audit body and SwissSign was held. The above questions by the Chrome Root Program were discussed and clarified. Defined actions are now being prepared and will be communicated separately.

Kind regards
Roman

Comment 10

[Stephan Verbücheln]

Please provide the answers to those questions in written form and in public.

Please note that your transparency obligations are not to the OS and browser vendors but to every single one of their users.