The purpose of a board is not to give credit to developers. The purpose of a board, especially a Kanban board, is to visualize the workflow.
In this particular case, I see a few possibilities. However, without a full understanding of your workflow, I'm not sure that I can recommend one particular approach.
One approach is to create a "release board" that visualizes the workflow of tasks that go into a release. You can create this board when you start the release process and use it to track all of the validation and release management activities, whether they are unique to a specific release or common across all releases. This type of board would give visibility to stakeholders as to how the release is progressing.
A second approach would be to add the work items to the team's Kanban board for the Sprint. Although the work is not associated with the Sprint, it still happens within the Sprint and affect's the team's capacity. However, the work for release management and validation may have a different workflow that makes this kind of configuration more difficult, depending on the workflow and the board columns.
You can also combine the approaches, with a release board for the detailed work, but a single card (or one card per person on the team) on the Sprint board to denote the people involved in assisting with release management and validation. The visibility into the release work would come from the release board, but it would also make it visible on the team board that people on the team are doing something else that impacts their availability and the team's capacity.
Personally, I would probably favor the first approach of creating a release board and having nothing on the Sprint board. However, if making the team's capacity visible on the team's Sprint board is important, I think the third option is best. I'm hesitant about combining two unrelated workflows on one board and the impact of that on clarity as well as any metrics that you use.
