Securing microservice applications is crucial. Security smells denote symptoms of bad –often unintentional– design decisions, which may result in violating security properties, and that can be resolved via refactoring. Stakeholders take into account the services’ business value, problem criticality, and available resources to decide which smells to resolve or leave alone, but making such decisions is inherently complex for microservice applications with many services, possibly affected by multiple security smell instances. Borrowing from hospital emergency room triage practices, which assign an urgency code to incoming patients, this paper introduces the notion of urgency for microservice security smell instances, and proposes the TriSS method to triage them. TriSS enables assigning to each security smell instance with an urgency code based on combining the services’ business relevance and the smells’ impacts on security and other quality attributes, e.g., performance and maintainability. The practical applicability of TriSS is illustrated with a use case based on a third-party microservice application, and its usefulness is evaluated with a controlled experiment involving 26 practitioners. The experiment’s results suggest that TriSS eases the triage process and yields urgency codes on which practitioners are more confident.