Thank you for reporting this. This is due to plugin keyless verification introduced in v0.55.
From the error, it looks like the transparency logs aren't included in the artifact attestation, but I'm not sure what cases that would happen.

Can you share the artifact attestation of the plugin you have installed?
You can see them in https://github.com/xxxx/tflint-ruleset-xxxx/attestations

@wata727 Here is the artifact attestation
attestation-sigstore (2).json

@wata727 Any update on the above issue ?

After some research, it appears that attestations built in private repositories do not include transparency logs.
https://docs.github.com/en/actions/security-for-github-actions/using-artifact-attestations/using-artifact-attestations-to-establish-provenance-for-builds#about-using-sigstore-for-artifact-attestations

Just like with GitHub CLI, we'll need to switch verification policies.
https://github.com/cli/cli/blob/v2.65.0/pkg/cmd/attestation/verification/sigstore.go#L282
https://github.com/terraform-linters/tflint/blob/v0.55.0/plugin/signature.go#L98-L103

It seems that we need GitHub Enterprise Cloud plan to test Artifact Attestations in private repositories.
https://docs.github.com/en/actions/security-for-github-actions/using-artifact-attestations/using-artifact-attestations-to-establish-provenance-for-builds

Supporting artifact attestations in private repositories can be difficult as we don't have sufficient funding to test the feature.
Plugins built in private repositories are likely secure enough, so skipping verification here might be a good start.

It seems like it should be possible to verify them as long as the transparency log option is off in the verifier. This does make sense, it's a private repository, it can't be identified in transparency logs.

I'm a GitHub Enterprise member so I can do one-time testing. We wouldn't have automated integration testing but it seems like the API difference is explicit enough that it won't be too hard to support. I would tend to agree that in practice external open source orgs are probably higher risk than internal compromises. But the sort of organization that wants to keep their plugins private is also more generally risk-averse and would want to defend against both.

@bendrucker Thank you for your suggestion!

Initially, I had a vision of forcing artifact attestations on all plugins, but given the plan limitations, I feel we need to have some kind of workaround for private plugins. If private plugins are always not verified, the verification behavior is always consistent without introducing an option like verify = true. However, If we provide an option to verify artifact attestations for private plugins, we will need to introduce verify = true|false option, which may seem dangerous at first glance.

This side effect requires some thought, but I agree with you that providing the option to verify could certainly be beneficial for risk-averse organizations. How about releasing v0.55.1 with #2223 to always skip verification, and then in next versions (0.56+) supporting artifact attestation for private plugins?

Yeah for sure, definitely patch it for the short term until we can test verification on a private repo.